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Researchers  at  the  U.S.  Army  Corps  of  Engi¬ 
neers  Construction  Engineering  Research  Labo¬ 
ratories  (USACERL)  have  been  developing  a 
collaborative  engineering  (CE)  software  envi¬ 
ronment  to  enable  sharing  of  design  information 
as  it  is  created  and  refined  during  the  facility 
design  and  construction  process.  Improved  in¬ 
formation  sharing  capabilities  and  conflict  man¬ 
agement  during  collaborative  design  enables  a 
team  to  resolve  design  issues  and  conflicts 
earlier  in  design  development,  resulting  in  an 
improved  facility  design,  fewer  errors  and  omis¬ 
sions,  and  better  interdisciplinary  coordination  of 
design  goals  and  building  systems. 
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for  a  construction  project  not  only  encourages 
those  involved  in  construction  to  use  and  add 
to  design  Information,  but  also  provides  richer 
information  representation,  better  efficiency 
and  data  consistency,  and  the  flexibility  to  sup¬ 
port  life-cycle  information  management. 

An  Important  part  of  the  CE  research  program 
at  USACERL  is  the  development  of  an  inte¬ 
grated  information  model  that  allows  agents  to 
communicate/collaborate  over  the  life  cycle  of 
the  project.  This  report  presents  a  CE  environ¬ 
ment  that  was  developed  to  support  collabora¬ 
tion  among  design  and  construction  agents. 
Lessons  learned  during  this  case  study  will  be 
used  to  reengineer  the  facility  delivery  process 
using  a  CE  approach. 
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1  Introduction 


Background 

The  life-cycle  cost,  quality,  durability,  and  reusability  of  facilities  built  for  the 
U.S.  Army  and  other  militeiry  services  is  important  during  an  era  of  increased 
competition  for  declining  resources.  More  money  is  spent  on  the  salaries  and 
benefits  of  the  people  working  or  living  in  a  facility  than  is  spent  on  designing, 
building,  maintaining,  conditioning,  and  operating  the  facility  during  its  useful 
Ufe.  According  to  Thomas  R.  Rutherford,  P.E.,  Assistant  for  Engineering  and 
Construction,  Office  of  the  Secretary  of  Defense,  “People  costs  consume  more 
thfin  95  percent  of  all  costs  in  terms  of  building  life-cycle  cost  evaluations,  when 
the  cost  of  the  people  in  the  building  are  included”  (Rutherford  1997).  Often, 
rnffitary  facilities  are  used,  reused,  remodeled,  and  renovated  for  many  years 
past  the  original  anticipated  life.  Also,  military  facilities  often  have  unique 
requirements,  special  restrictions,  or  hostile  environments  which  can  complicate 
the  design/construction  process. 

The  Department  of  Defense  (DOD)  spends  $8.8  billion  annually  on  new 
construction,  $94  billion  on  operation  and  maintenance  (O&M)  of  facilities,  and 
has  a  $14  billion  backlog  of  maintenance.  On  8  July  1997,  the  U.S.  House  of 
Representatives  approved  $9.2  billion  in  new  spending  authority  for  military 
construction.  While  the  measure  is  nearly  $800  million  above  President 
Clinton's  Fiscal  Year  (FY)  1998  budget  request,  it  is  $610.3  million  less  than  m 
FY97,  reflecting  a  6-percent  reduction.  According  to  LTG  Joe  N.  Ballard, 
Comi^ander,  U.S.  Army  Corps  of  Engineers  (USACE),  military  budgets  will  not 
even  keep  up  with  the  cost  of  inflation  in  the  foreseeable  future.  Therefore,  a 
way  must  be  found  to  use  scarce  resources  more  effectively,  and  to  reengineer 
business  practices  to  improve  productivity  while  permanent  civilian  staff 
positions  are  being  cut  (USACERL  Townhall  Meeting,  27  June  1997). 

The  Army  Corps  of  Engineers  manages  the  design  and  construction  of  military 
facilities,  civil  works  projects,  and  environmental  remediation  projects  for  the 
Army  and  other  customers.  Private  A/E  firms  designed  approximately  75 
percent  of  the  facilities  built  for  the  Army  in  FY95  at  a  cost  of  $319  million. 
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Almost  all  of  the  $4.2  billion  in  Army  construction  in  the  United  States  was 
accomplished  by  private  sector  firms  during  FY95.  Substantial  savings  could  be 
realized  by  placing  more  emphasis  on  optimizing  the  facility  design  to  reduce 
costs  over  the  facility’s  life  cycle. 

Each  project  fypicedly  involves  many  people:  owner  representatives  (from  the 
using  agency  and  host  installation),  contracting  officers,  designers  and  con¬ 
sultants  (in-house  or  contracted),  reviewers  (design,  constructibility,  operation, 
functionality,  and  maintenance),  and  builders  (typically  private  sector  con¬ 
tractors).  A  typical  Military  Construction  -  Army  (MCA)  project  can  last  3  to  5 
years  from  initial  project  scoping  to  completion  of  construction  and  is  governed 
by  procurement,  design,  energy,  construction,  and  other  regulations.  This  facility 
dehvery  process  includes  periodic  design  reviews,  yet  may  not  ensure  that  the 
completed  facility  satisfies  client  requirements,  which  can  change  during  the  3- 
to  5-yr  process.  A  large  project  such  as  a  medium-sized  hospital  might  take  even 
more  time — ^up  to  8  years — ^to  plan,  design,  construct,  and  conunission.  Another 
complication  is  that  the  military  often  constructs  facility  types  nnfaTniliar  to  the 
commercial  Architectural/Engineering  (A/E)  firms  and  contractors  who  design 
and  build  them. 

Several  business  reengineering  studies  and  working  groups  have  concluded  that 
the  facility  delivery  process  should  be  improved  by  reengineering  the  process, 
shortening  delivery  time,  and  using  computer  technologies  to  improve  design/ 
engineering  productivity. 

At  the  1996  Worldwide  Area  and  Resident  Engineer  and  Contracting  Training 
Seminar,  MG  Albert  J.  Genetti,  Jr.,  Director  of  Military  Programs,  discussed  the 
Corps  Wsion:  “Being  a  vital  part  of  America’s  Army,  building  for  the  future  and 
providing  quality,  responsive  engineering  services  to  support  the  Nation  in  Peace 
and  War...”  and  his  goal  for  the  Corps  to  become  a  “Seamless  Ifeam”  to  our 
various  customers.  He  spoke  briefly  about  ongoing  Army-wide  efforts  to 
reexamine  and  reengineer  its  construction  function.  The  Corps  led  an  Army¬ 
wide  effort  of  major  Army  command  (MACOM)  representatives  to  recommend  to 
Army  leadership  how  the  Army  could  better  support  the  construction,  engi¬ 
neering,  environmental,  and  real  estate  needs  of  its  installations.  Key  study 
recommendations  are  to  look  at  more  privatization  or  outsourcing  of  functions, 
streamline  management  processes,  and  find  smarter  ways  to  do  business.  MG 
Genetti  specifically  mentioned  MDS  (Modular  Design  System)  as  a  bright 
possibility  for  the  future  [U.S.  Army  Corps  of  Engineers,  June  1996].  He  also 
said,  “Quality  is  as  important  as  execution.  Quality  is  our  most  important 
product.”  Key  capabilities  of  the  testbed  technology  described  in  this  report  are 
being  incorporated  by  USACERL  into  future  versions  of  MDS. 
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The  Army  Corps  of  Engineers  is  developing  campaign  plans  to  implement  the 
Corps’  Strategic  Vision  authored  by  LTG  Ballard  (USACE  1997).  The  1997 
HQUSACE  Campaign  Plan  shows  that  Team  4  (Virtual  Team  Initiative)  is  co¬ 
chaired  by  the  Directors  of  Information  Management  and  Human  Resources. 
Their  task  is  to: 

develop  and  implement,  by  15  September  1997,  a  plan  to  promote 
‘Sdrtual  teams”  in  the  Corps  of  Engineers.  The  plan  include 
identifying  the  technical  means,  cultural  gaps,  changes  to  policy,  training 
needed,  executive  responsibilities,  and  management  systems  necessary  to 
create  the  environment  needed  for  virtual  teams.  The  plan  must  allow 
the  Corps  to  be  rapidly  responsive  and  flexible — an  organization  able  to 
adapt,  tap  talent  and  expertise,  distribute  work,  and  produce  engineering 
products  and  services  without  the  need  for  either  physical  reorgamzation 
or  co-location  of  resources.  The  plan  will  leverage  advanced  information 
technologies  and  the  right  kind  of  organizational  climate— one  mth 
supportive  culture  and  relationships.  Corps  members  will  have  seamless 
access  to  information  and  ease  in  performing  data  aggregation, 
summarization,  and  retrieval.  The  goal  is  to  unprove  commumeations, 
customer  satisfaction,  and  services  and  to  facilitate  the  “one  door  to  the 
Corps”  concept.  This  may  require  challenging  basic  assumptions  about 
the  organization  and  norms. 


Collaborative  engineering  (CE)  software  that  would  allow  teams  of  people  in 
various  locations  to  design  facilities  is  essential  for  virtual  design  teams. 


Engineering  Focuses  and  Initiatives  listed  the  following  focuses:  (1)  simplifica¬ 
tion  of  design  process,  (2)  quahty  design,  (3)  cost  of  doing  business,  (4)  partner¬ 
ing,  (5)  installation  support,  and  (6)  combat  readiness  support.  During  recent 
years,  the  number  of  Army-unique/Federal/military  specifications  have  been 
dramatically  reduced,  being  replaced  with  mostly  commercial  or  industry-wide 
standards  (HQUSACE,  December  1995).  On  16  February  1995,  LTG  Arthur  E. 
Williams,  then  Chief  of  Engineers,  issued  a  Master  Action  Plan  (MAP)  requiring 
all  USACE  solicitations  issued  after  10  October  1995  to  be  either  free  of  military 
specifications  (MIL-SPECs)  and  military  standards  (MIL-STDs)  or  have  waivers 
in  place  for  those  remaining.  Another  pending  design  process  change,  which  vfill 
begin  with  the  FY98  military  construction  (MILCON)  program,  is  the  replace¬ 
ment  of  the  “35%  design  phase”  with  a  “Project  Engineering  (PE)  phase”  using 
parametric  estimating  and  a  design  charette  process.  The  only  exceptions  to  this 
change  -will  be  those  projects  of  a  complex  or  imique  nature  for  which  there  is 
little  or  no  historical  design  and  cost  data  (USACE,  4  April  1997).  Other  initia¬ 
tives  being  studied  are  ways  to  improve  engineering  and  design  productivity 
through  the  use  of  computers  and  digital  technologies,  simplified  design,  a 
streamlined  review  process,  timely  coordination  and  teamwork,  and 
restructuring  and  reengineering  the  Corps  organization. 
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A  recently  released  Civil  Engineering  Research  Foundation  (CERF)  report 
(CERF  1996)  lists  38  research  topics  or  challenges  facing  the  construction  and 
engineering  industry  with  respect  to  environmentally  sustainable  infrastructure. 
Generated  by  a  global  team  of  more  than  700  construction  and  engineering 
experts,  the  Global  Research  Agenda  calls  for  innovation  in  technology  based  on 
seven  themes: 

•  applying  global  standards  and  performance  criteria 

•  utilizing  demonstration  projects  to  accelerate  innovation 

•  expanding  the  industry  base 

•  streamlining  the  construction  process 

•  creating  new  tools  eind  methods 

•  bringing  imderstanding  to  industry,  government,  and  the  public 

•  defining  sustainability  operationally. 

Participants  were  divided  into  five  industry  groups: 

•  Management  and  Business  Practices 

•  Design  Ibchnologies  and  Practices 

•  Construction  and  Equipment 

•  Materials  and  Systems 

•  Public  and  Government  Policy. 

The  Management  and  Business  Practices  group  placed  heavy  emphasis  on 
Streamlining  tfre  Construction  Process.  USACERL’s  CE  research  effort  is 
specifically  mentioned  in  Focus  Area  1:  Management  and  Business  Practices, 
Tbpic  1.9,  Promoting  Seamless  Knowledge  Transfer  in  Construction.  The 
objective  of  this  topic  is:  "Ib  promote,  coordinate,  and  monitor  ^yisting  and  new 
efforts  that  establish  common  global  protocols  for  storage  and  transfer  of 
information  regarding  all  aspects  of  the  design,  construction,  and  operation  of 
built  facilities.” 

The  Creating  New  Analytical  Tools  and  Methods  group  research  topics  are  also 
related  to  USACERL’s  CE  effort.  The  overview  emphasizes  that  collaboration  is 
the  key  to  the  engineering  and  construction  industiys  success  in  the  next 
century.  This  technology  gap  can  be  bridged  by  developing  a  truly  collaborative 
design  environment. 

Even  with  existing  Computer-Aided  Design  (CAD)  automation,  many  oppor- 
tumties  exist  in  the  current  design  process  to  improve  the  quality  while  reducing 
errors  and  total  life-cycle  costs.  Drawings  and  other  information  developed 
during  the  design  phase  are  not  readily  incorporated  into  information  systems 
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required  for  construction  management  (i.e.,  project  management,  scheduling, 
progress  payments)  and  O&M  (i.e.,  Engineering  Management  Systems  [EMS], 
Computer  Aided  Facility  Management  Systems  [CAFMS]).  This  situation 
applies  to  both  government-supported  and  commercial  off-the-shelf  (COTS) 
software.  Additional  benefits  would  be  gained  by  reducing  errors  in  construction 
documents  and  improving  tradeoffs  between  competing  engineering  goals  in 
facility  design.  Better  as-built  documentation  is  desired  by  those  who  manage 
and  maintain  the  facilities. 


Use  of  a  CE  design  environment  that  enables  all  design  participants  to  add  and 
share  information  throughout  the  design  and  construction  process  would  greatly 
improve  communication  and  coordination.  A  structured  information  infrastruc¬ 
ture  could  support  computable  facility  models  throughout  their  life  cycle  as  they 
are  developed  during  the  design  phase  and  passed  downstream  to  construction 
management  and  O&M  phases.  An  integrated  information  model  not  only 
encourages  those  involved  in  construction  to  use  and  add  to  design  information, 
but  also  provides  richer  information  representation,  better  efficiency  and  data 
consistency,  and  the  flexibihty  to  support  life-cycle  information  management. 
The  resulting  facility  model,  in  combination  with  as-built  documents  in  a 
structured  electronic  format,  could  serve  as  the  foundation  for  all  information 
about  the  facility  during  its  life  cycle. 

It  is,  therefore,  essential  that  the  multidisciphnary  teams  who  design,  build,  and 
operate  such  facilities  have  access  to  collaborative  design  tools  and  an  integrated 
information  model  that  allows  them  to  share  current  information,  avoid  redun¬ 
dant  input,  access  appropriate  analysis  tools,  detect  conflicts,  and  collaborate 
with  other  team  members  both  in  the  same  office  and  at  other  locations. 


Objectives 

The  objective  of  this  research  was  to  develop  an  integrated  information  model  to 
allow  coUaboration  over  a  project’s  life  cycle.  CE  is  a  technology-based  design 
and  construction  management  approach  that  emphasizes  four  principles:  (1) 
simplification  of  existing  serial  design  and  construction  processes,  (2)  global  opti¬ 
mizing  of  facility  design  through  support  for  team  collaboration,  negotiation,  and 
group  decisionmaking,  (3)  incorporation  of  downstream  requirements  such  as 
maintenance,  operations,  environment,  and  other  life-cycle  issues  into  the  design 
process,  and  (4)  development  of  robust,  integrated  product  and  process  model 
representations  that  can  evolve  and  be  used  throughout  the  faciUty  life  cycle. 
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A  fully  implemented  collaborative  environment  wiU  significantly  improve  the 
quality  of  decisionmaking,  contract  documentation  and  related  design  processes. 
Through  agent-assisted  collaboration,  the  extended  design  groups  (including 
construction,  operations  and  maintenance  [O&M],  and  other  installation 
personnel)  work  as  a  coordinated  team.  Software  agents  will  assist  designers  in 
making  decisions  based  on  improved  information  dissemination  and  conflict 
management.  Designers  will  have  the  capability  to  effectively  consider  a  wider 
variety  of  design  solutions  and  evaluate  additional  alternatives  to  improve  the 
quality,  health  and  comftrt,  energy  efficiency,  and  life-cycle  cost  effectiveness  of 
the  facility.  Making  these  types  of  analyses  easy  to  perform  will  mean  facilities 
that  perform  better  functionally  and  at  reduced  operational  expense. 


Scope 

This  report  describes  a  hardware  and  software  environment  that  illustrates  the 
following  key  CE  goals: 

•  a  shared  workspace  that  allows  participants  to  view  common  elements  of  a 
facility  design,  while  at  the  same  time  providing  legitimate  privacy  needs 

•  a  common  communication  protocol  and  representation  schema  for  design 
information 

•  identification  of  conflicts  between  design  participants 

•  a  capability  for  participants  to  use  software-based  agents  to  represent  them 
in  the  design  process 

•  an  open  architecture  that  allows  participants  to  link  industry  standard  CAD, 
database,  analysis  software  and  custom  applications  into  the  CE  software 
environment. 

The  research  presented  in  this  paper  was  performed  imder  the  auspices  of  the 
CE  research  program  at  USACERL,  which  is  attempting  to  redefine  pvifiting- 
design  processes  to  make  Idiem  more  collaborative  and  develop  enabling 
technologies  to  support  the  new  process.  An  important  part  of  this  research  is 
the  development  of  an  integrated  information  model  that  allows  agents  to 
communicate/collaborate  over  the  life  cycle  of  the  project.  This  report  presents  a 
CE  environment  which  was  developed  at  USACERL  to  support  collaboration 
among  design  and  construction  agents. 

USACERL’s  case  study  or  design  testbed  demonstrates  how  design  information 
evolves  during  the  design  development  and  construction  planning  phases  of  a 
facihty.  Lessons  learned  during  this  case  study  will  be  used  to  reengineer  the 
facility  delivery  process  using  a  CE  approach. 
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Approach 

The  testbed  project  was  a  coordinated  effort  to  produce  a  demonstration  of 
integrated  software  tools  and  agents  which  can  perform  collaborative  design  and 
analysis  tasks  using  a  shared  facility  model.  Key  aspects  of  the  testbed  which 
were  studied  for  this  report  include; 


•  technology 

•  scenario 

•  agents 

•  shared  facility  model 

•  collaborative  design  process. 

The  CE  research  program  at  USACERL  has  been  an  ongoing  effort  for  the  last  3 
years  and  is  composed  of  several  research  projects.  The  following  USACERL 
projects  participated  in  the  testbed  demonstration: 


project  Title 
Closely-coupled  Collaborative  Workspaces 
Generative  Design  Strategies 
Agent  Collaboration  Language 
Construction  CADD 
CJenerative  Design  Methods 
Domain  Knowledge  Structure  and  Process 
Design  Reviewer’s  Support  Environment 
Agent  Based  Collaborative  Methods  for 
Energy  System  Design 
Expert  System  Analysis  &  Concurrent 
Engineering  for  ESD 

As  a  part  of  this  effort 
accomplished: 


Work  Unit# 

Princinal  Investieator 

AT23-FF-EA5 

Phil  Lawrence 

AT23-FF-EC5 

Eric  Griffith 

AT23-FF-EF5 

Michael  Case 

AT41-FF-AS5 

Annette  Stumpf 

AT41-FF-AG5 

Eric  Griffith 

AT41-FF-AR5 

Beth  Brucker 

AT41-FF-AP5 

William  East 

AT45-FE-X55 

Kirk  McGraw 

AT45-FE-XS5 

Michael  Case 

and  related  USACERL  projects,  the  following  tasks  were 


•  the  current  MCA  design/construction  process  (facility  delivery  process)  was 
analyzed 

•  efforts  to  improve  the  MCA  process  were  identified,  along  with  case  studies 
and  targeted  areas  for  improvement 

•  current  design  tools,  CAD  standards,  and  A/E  deliverables  were  investigated 

•  a  subset  of  the  MCA  design  activities  was  chosen  for  this  project 

•  the  testbed  scenario  and  new  collaborative  design  process  were  developed 

•  identified  which  “agents”  should  be  developed  to  implement  the  scenario 
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•  developed  shared  object-oriented  (0-0)  facility  model 

•  conducted  two  literatime  searches  of  available  technologies  and  tools  (Case  et 
al.  1994,  Ganeshan  1996) 

•  selected  most  smtable  CE  software  technologies,  assuming  legacy  tool 
integration 

•  developed/integrated: 

-  software  tools  with  the  collaborative  design  environment  using  the  Agent 
Collaboration  Environment  (ACE) 

-  conflict  resolution 

-  CAD  talk 

-  commercial  software  tools  such  as  BLAST*,  Microsoft  Project,  Microsoft 
Excel,  MCACES,  AutoCAD,  and  MicroStation 

•  developed  agents  (Project  Management,  Architectural  Layout,  Construction 
Planning,  Cost  Estimating,  Roofing  Design,  Code  Checking) 

•  tested  all  the  research  products  listed  above  using  a  fire  station  and  battalion 
headquarters  as  a  case  study  project 

•  documented  the  testbed  research  and  lessons  learned  in  several  USACERL 
techmcal  reports,  presentations,  and  conference  papers. 

While  the  testbed  research  was  proceeding,  USACERL  also  directed  and  partici¬ 
pated  in  a  related  collaboration  effort,  called  Agent  Collaboration  Language 
(ACL)  in  cooperation  with  several  universities,  including  the  University  of 
Illinois  at  Urbana-Champaign  (UlUC),  Stanford  University,  Carnegie  Mellon 
University  (CMU),  and  the  Massachusetts  Institute  of  Technology  (MIT).  This 
parallel  efibrt  attempted  to  enable  collaborative  design  and  analysis  by  trans¬ 
lating  between  participants  using  different  facflity  models.  The  ACL  project 
used  Stanford  University’s  Facilitator  Architecture  to  translate  between  dif¬ 
ferent  domain  schemes.  UIUC  conducted  energy  analysis  for  the  facility  using 
BLAST,  CMU  used  SEED^  for  architecture  layout,  MIT  performed  structural 
analysis,  and  USACERL  managed  the  project  (Khedro  et  al.  1995  and  1996). 

Mode  of  Technology  Transfer 

USACERL  has  signed  a  Cooperative  Research  and  Development  Agreement 
(CRaDA)  agreement  with  GoldHill,  Inc.,  to  develop  a  commercial  product  based 
on  ACE. 


*  BLAST  =  Building  Loads  Analysis  and  Systems  Thermodynamics. 

’  SEED  =  Software  Environment  To  Support  Early  Phases  in  Building  Design. 
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Many  of  the  concepts  and  software  tools  developed  during  the  testbed  project  will 
be  incorporated  in  future  versions  of  design  software  called  the  Modular  Design 
System  (MDS).  The  MDS  CRaDA  was  signed  18  July  1996  with  Bentley 
Systems,  Inc.,  Building  Systems  Design,  Inc.,  IdeaGraphix,  Inc.,  and  JMGR,  Inc. 
USACERL  is  responsible  for  execution  of  research  and  development  (R&D)  in 
support  of  MDS.  In  addition  to  Army  Corps  of  Engineers  organizations 
(HQUSACE,  USACERL,  WES,  and  the  Louisville  Engineer  District),  the  MDS 
Development  Team  includes  the  U.S.  Army  Reserve,  the  Army  National  Guard, 
and  the  industry  partners  listed  above.  The  University  of  Southern  California, 
UrUC,  and  CMU  are  also  involved  in  this  collaborative  effort  (Case  1997). 

Four  members  of  the  testbed  project  are  actively  contributing  their  experience 
and  expertise  in  developing  a  shared  facility  model  with  the  International 
Alliance  for  Interoperability  (lAI).  lAI  is  developing  Industry  Foundation 
Classes  (IFC)  that  will  enable  IFC-compliant  software  to  exchange  an  object- 
oriented  facility  model.  The  lAI  is  a  nonprofit  alliance  of  the  building  industry 
including:  architects,  engineers,  contractors,  building  owners,  facility  managers, 
building  project  manufacturers,  software  vendors,  information  providers,  govern¬ 
ment  agencies,  research  facilities,  and  universities  with  member  chapters  in 
North  America,  Germany,  the  United  Kingdom,  France,  Singapore,  Nordic 
countries,  and  Japan.  Its  mission  is  to  integrate  the  AEC/FM  mdustry  by 
specifying  IFC  as  a  universal  language  to  improve  the  communication,  pro¬ 
ductivity,  delivery  time,  cost,  and  quality  throughout  the  design,  construction, 
and  O&M  life  cycle  of  buildings.  The  Alliance  is  committed  to  taldng  advantage 
of  the  collective  power  of  the  industry  to  produce  a  standard  for  communication 
promoting  collaborative  efforts  and  global  expansion.  The  lAI  IFCs  will  serve  as 
an  information  infrastructure  for  future  versions  of  MDS  software  (lAI  1997). 

Incorporating  concepts  and  technology  developed  during  the  testbed  project, 
“Project  CITY”  is  a  joint  program  of  the  Army  and  the  National  Science  Founda¬ 
tion  High  Performance  Computing  and  Communications  program  (Lu  et  al. 
1994).  The  project  is  developing  a  workbench  of  software  tools,  CITYSCAPE, 
that  will  help  improve  teamwork  in  public  works  management. 

Ultimately,  if  lAI  IFCs  become  industry  standard,  and  the  Tri-Services  CADD 
Center  endorses  them  as  a  portion  of  future  CAD  standards.  Corps  of  Engineers 
Districts  and  Divisions;  Headquarters,  U.S.  Army  Corps  of  Engineers,  other 
DOD  and  government  agencies  engaged  in  the  acquisition  of  facilities,  and  the 
construction  industry  at  large  will  be  able  to  produce  computable  designs  that 
can  be  developed  and  exchanged  using  commercial  design  and  analysis  tools. 
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MDS  Version  2.0  was  delivered  15  April  1997.  Scheduled  for  delivery  in  October 
1999,  MDS  Version  3.0  will  be  based  on  an  open,  object-oriented  technology 
developed  through  partnering  with  leading  vendors  and  A/E  firms.  MDS  Version 
4.0,  planned  to  be  available  in  October  2001,  will  add  CE  capability  to  allow 
virtual  teams  to  work  together  over  the  Internet. 
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2  Opportunities  for  improvement  in  the 
Design/Construction  Process  Using 
Coiiaborative  Engineering  Toois 


Introduction 

The  Army  is  the  largest  facility  owner  in  the  Federal  Government.  Its  facility 
delivery  processes  must  be  improved  in  order  to  meet  existing  and  future 
requirements,  despite  reduced  persoimel  and  funding.  In  the  context  of  this 
report,  facilities  refers  to  buildings  (e.g.,  armories.  Reserve  centers,  barracks, 
training  centers)  that  are  designed,  engineered,  and  constructed  by  the  Army 
Corps  of  Engineers,  Army  Reserve,  National  Guard,  and  Air  Force.  Although 
conventional  facility-delivery  processes  and  practices  successfully  produce 
facilities,  these  facilities  frequently  are  not  delivered  in  time  to  meet  the  original 
requirements  and  can  exceed  the  established  budget.  By  the  time  a  facility  is 
delivered,  user  requirements  can  be  nearly  5  years  old,  the  delivered  facility  may 
only  satisfy  a  portion  of  updated  requirements,  and  the  cost  is  excessive.  As 
discussed  in  Chapter  1,  drawings  and  other  information  developed  during  the 
design  phase  are  not  readily  incorporated  into  information  systems  required  for 
construction  management  and  O&M.  This  incompatibility  applies  to  both 
government-supported  and  commercial  software. 


Computer-based  Project  Information  Management  System 

Enabled  by  low-cost  yet  powerful  personal  computers  (PCs),  the  Architectural/ 
Engineering/Construction  (A/E/C)  industry  is  using  computers  intensively  in 
their  tasks.  Similarly,  facility  operators  and  maintainers  are  given  plenty  of 
choices  of  facility  management  software  to  plan  and  execute  the  day-to-day 
operations.  Computer-based  systems  have  increased  the  quality,  productivity, 
and  efficiency  of  design,  construction,  and  facility  O&M.  Accompanied  by  these 
improvements  come  the  challenge  and  opportunity  to  transfer  integrated 
information  from  one  entity  to  another,  and  from  one  phase  to  another.  What  is 
desired  is  an  integrated  information  management  structure  that  supports 
activities  throughout  the  life  of  a  facility— an  integrated  system  for  consistently 
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managing  drawings  and  project  information  during  facility  design,  construction, 
and  O&M.  Ideally,  a  system  that  is  used  by  designers  and  engineers  can  be 
updated  by  contractors  to  post  changes  and  as-builts,  and  eventually  can  be  used 
by  facility  operators  and  maintainers  to  manage  their  tasks.  Figure  1  shows  the 
concept  of  ideal  facility  life-cycle  information  integration  from  design  to  disposal 
of  a  facility.  The  bins  represent  information  created,  shared,  refined,  and  added 
to  the  facility  model  during  each  stage  of  the  facility  delivery  process.  The  figure 
shows  an  electronic  model  of  the  facihty  created  during  design,  using  either 
intelligent  CAD  drawings  or  object-oriented  3-D  CAD  drawings  with  data 
associated  to  the  drawing  elements  (or  objects).  At  each  subsequent  stage  of  the 
facility  delivery  process,  relevant  information  is  added  to  the  facility  model, 
including  as-biiilt  information,  warranties,  and  O&M  information.  The  resulting 
facility  model  can  then  be  used  throughout  the  facility’s  life  cycle.  This 
information  integration  not  only  provides  the  needed  information  infrastructure 
to  store/retrieve  life-cycle  information,  but  also  reduces  inconsistent  and 
inaccurate  information.  Because  of  the  large  amoimt  of  data,  all  information  is 
stored  on  CD-ROMs  (Stumpf  et  al.  1995). 


Planning/Design 


>  Functional  Req. 
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'Drawings 
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Figure  1.  Facility  life-cycle  information  management. 
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Total  Quality  in  the  Facility  Design  Process 

Total  quality  is  a  client-focused,  strategic,  and  systematic  approach  to  the 
continuous  improvement  of  performance.  Total  Quality  Management  (TQM)  is  a 
management  method  to  improve  the  quality  of  the  work  we  do.  When  analyzing 
the  facdity  design  process,  this  means  that  efforts  must  be  made  to  measure  and 
evaluate  the  existing  process,  identify  the  sources  of  problems,  and  optimize  or 
reengineer  the  process  (sometimes  radically)  to  reduce  unnecessary  activities, 
eliminate  errors,  and  speed  the  process. 


Without  metrics,  it  is  impossible  to  determine  if  a  change  to  a  process  is 
beneficial  or  if  it  improved  quality  Quality  can  often  be  measured  either  by 
qualitative  or  quantitative  measures.  Most  tools  used  in  TQM  were  developed 
for  quantitative  analysis  primarily  aimed  at  the  manufacturing  of  products,  not 
services.  Emphasis  is  placed  on  cormting  errors  as  a  percentage  of  total  products 
manufactiired.  Statistical  analysis  requires  measurable,  objective  data,  which  is 
best  obtained  in  producing  tangible  products. 

The  construction  industry  is  fundamentally  different  from  manufacturing  in 
quantity  of  products  being  designed.  The  manufacturing  process  provides 
significant  feedback  because  of  the  sheer  numbers  of  goods  being  manufactured 
from  a  single  design.  Quality  control  provides  feedback  allowing  the  design  to  be 
improved  over  time.  On  the  other  hand,  the  construction  industry  rarely  builds 
more  t>iaTi  one  facility  from  a  single  design.  This  lack  of  feedback  causes  the 
facility  design  to  suffer  and  its  processes  to  be  less  optimized. 

Measures  of  Quality 

Quantitative  measures  do  exist  in  architecture.  Various  metrics  such  as  the  net- 
to-gross  ratio,  unit  and  system  cost  metrics,  cost  growth  through  change  orders, 
or  hours  to  complete  a  drawing  sheet  are  all  useful  measures.  However,  few 
relate  directly  to  quality  as  it  would  be  understood  by  most  architects. 


As  a  result  of  TQM,  there  is  now  interest  in  finding  metrics  related  to  the  design 
process  itself.  One  study  identified  both  short-  and  long-term  metrics  that  could 
be  used  for  the  design  process  (Culp,  Smith,  and  Abbott  1993). 

Short-term  metrics. 

•  number  of  scheduled  milestones  missed 

•  amoimt  of  overtime  by  staff 

•  cost  of  drawing/specification  rework  after  final  check 
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•  number  of  inconsistencies  between  drawings  and  specifications 

•  number  of  errors  per  drawing 

•  hoinrs  and/or  cost  per  drawing 

•  ratio  of  project  engineering/architecture  cost  to  budget  amount 

•  submittal  (shop  drawings)  review  time 

•  response  time  to  contractor  requests  for  information 

•  number  of  typographical  errors  per  page  on  resume,  report,  or  other  printed 
work. 

Long-term  metrics. 

•  turnover  rate  of  technical  staff 

•  success  rate  on  proposals  submitted 

•  project  budget  overruns  (firequency  and  amount) 

•  cost  of  marketing  as  a  percentage  of  total  fees 

•  number  of  times  a  document  is  changed  after  it  is  issued 

•  number  of  formal  reviews  conducted  on  time 

•  dollar  amount  of  field  changes 

•  number  of  contractor  requests  for  information 

•  change  orders,  expressed  as  percentage  of  project  construction  costs 

•  ratio  of  final  construction  cost  to  estimated  construction  cost 

•  client  perception  of  project  quality  and  consultant  responsiveness 

•  claims,  settlement,  and  litigation  expense. 

The  University  of  Maryland's  Architecture  and  Engineering  Performance 
Information  Center  (AEPIC)  used  litigation  as  a  metric  directly  related  to  the 
quality  of  the  facility  and/or  its  process.  AEPIC  analyzed  5,000  buildings  and 
2,500  civil  works  projects  that  suffered  fi'om  performance  failures.  The  data 
anal3rzed  were  primarily  fi'om  professional  liability  cases,  the  ultimate  measure 
of  quality.  Performance  failm-es  in  this  report  are  defined  as  “the  results  of  the 
imfulfiUment  of  a  claim,  promise,  request,  need,  or  expectation  between  the 
design  professional,  contractor,  owner,  user,  or  any  other  party  to  the  building 
process.” 

AEPIC  found  that  five  btiilding  systems  (mechanical,  roofing,  structxu-al, 
sitework,  and  envelope)  were  responsible  for  52  percent  of  the  total  incidents. 
For  these  claims,  41  percent  were  the  result  of  architectural  services,  34  percent 
were  engineering  services,  and  16  percent  were  for  construction  services.  When 
looking  at  the  reasons  for  performance  incidents,  44  percent  were  for  design 
services,  17  percent  were  for  construction  services,  and  7  percent  were  for  specifi¬ 
cation  writing  (Loss  1991). 
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Emphasizing  the  TQM  process,  the  Corps  of  Engineer’s  LouisviUe  District 
created  a  Cost  of  Doing  Business  Process  Action  Team  (CODE  PAT)  to  study  how 
architects  and  engineers  do  business  in  their  organization.  Using  metrics 
similar  to  those  discussed  above,  the  PAT  set  out  to  examine  new  strategies  to 
save  design  time,  save  money,  and  to  standardize  design  procedures.  They 
wanted  to  develop  a  new  design  process  to  make  their  A/E  Division  more  efficient 
and  cost  effective,  enhancing  the  Corps’  image  and  making  them  more 
competitive.  One  of  their  major  conclusions  was  the  need  to  have  a  greater 
emphasis  on  the  “team  concept.”  They  felt  the  team  concept  offered  a  forum  for 
promoting  a  strong  partnering  agreement  with  the  customer.  It  would  also  allow 
designers  to  talk  face  to  face  with  individuals  who  will  be  reviewing  the  project 
to  find  out  their  expectations  while  still  being  able  to  gather  the  necessary 
information  to  start  project  design  (Basham  et  al.  1993). 

The  team  concept  and  identification  of  other  metrics  that  directly  relate  to  the 
design  are  useful  in  looking  at  the  process  and,  in  particular,  the  breakpoints 
and  time-consuming  efforts  within  the  process.  With  this  in  mind,  USACERL 
studied  the  traditional  process  in  the  Corps  of  Engineers  as  it  relates  to  the  team 
concept,  which  is  now  enhanced  with  the  development  of  CE  systems,  the 
Internet,  and  the  World  Wide  Web. 


The  Army  Facility  Delivery  Process 

USACERL  researchers  have  been  working  to  improve  both  the  facility  delivery 
process  and  the  quality  of  the  constructed  facility.  Leverenz  et  al.  (1983) 
analyzed  the  MCA  building  delivery  process  to  identify  the  process  steps,  phases, 
participants,  decision  points,  legal  and  technical  requirements,  and  products.  All 
regulations  pertaining  to  the  MCA  process  and  energy-related  issues  were 
analyzed  to  determine  the  energy  impacts  of  design  and  construction  decisions. 
Similar  investigations  were  conducted  on  two  variations  of  the  traditional  two- 
step  building  delivery  process;  (1)  the  Army  Design/Build  process  (Napier  1990) 
and  (2)  the  Army  Third  Party  Construction  process  (Napier  1993).  Then 
USACERL  developed  a  detailed  “Discourse  Model”  of  how  participants 
collaborate  during  the  design  process  (Case  1994  and  1996).  Building  upon  this 
research,  the  entire  facility  delivery  process  was  analyzed  and  documented  in 
detail  (Stumpf  et  al.  1996).  The  traditional  design  process  was  studied,  along 
with  recent  efforts  to  improve  the  process.  Next,  the  construction  process  was 
analyzed  from  the  Resident  Engineer’s  viewpoint  to  determine;  (1)  the  type  and 
format  of  design  information  that  goes  into  the  construction  process,  (2)  how 
Resident  Engineers  use  the  information  during  construction,  (3)  what  kind  of  as- 
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built  and  project  control  information  is  collected  during  construction,  and  (4)  the 
t3^e  and  format  of  the  as-built  information  delivered  to  the  facility’s  owner. 
Special  attention  was  given  to  the  use  of  CAD  technologies  and  information 
systems  used  by  Resident  Engineers  during  the  construction  phase  (Stmnpf 
1994).  A  study  of  as-built  project  information  used  (and  desired)  during  facihty 
management  and  O&M  was  also  conducted  (Liu  1994).  Finally,  a  new  design 
process  was  developed  to  enable  designers  to  effectively  use  the  new  CE  and 
communication  technologies  to  improve  the  facility  design  while  shortening  the 
facility  delivery  process. 

Traditional  MCA  Facility  Delivery  Process 

Participants,  responsibilities,  and  products/documents.  The  facility  design  and  con¬ 
struction  process  involves  many  participants,  from  various  organizations,  who 
create,  change,  analyze,  evaluate,  and  comment  on  a  large  volume  of  shared  and 
proprietary  design  alternatives  and  information  imtil  the  design  is  finalized. 
Even  after  construction  begins,  further  changes  and  modifications  are  needed. 
Before  the  facility  can  be  handed  over  to  the  owner,  accurate  as-built  and  project 
control  information  must  be  collected  to  describe  the  actual  components  which 
were  purchased  and  installed  in  the  facility  (Stumpf  1996). 

Figure  2  depicts  the  participants  and  major  activities  that  occm-  dining  the  MCA 
design  and  construction  process.  Table  1  shows  responsibilities,  requirements, 
and  products  at  each  phase  of  the  process.  Funding  for  each  MCA  project  must  be 
approved  by  Congress  as  part  of  the  overall  Army  Stationing  and  Installation 
Plan  and  the  Long  Range  Construction  Plan.  A  limited  construction  budget  is 
available,  and  all  projects  are  prioritized  and  ranked.  Only  those  at  the  top  of 
the  list  are  funded  each  year.  This  budget  approval  cycle  repeats  each  year, 
while  budget  constraints  increase,  and  new  construction  priorities  appeeur.  Once 
funding  is  approved  for  an  MCA  project,  the  design  and  construction  process 
typically  takes  between  3  and  5  years,  unless  the  building  is  large  and  very 
compUcated,  such  as  a  hospital  or  chemical  demilitaiization  plant. 

Traditional  Design  Process 

Figure  3  diagrams  the  flow  of  the  traditional  design  process  and  its  activities, 
and  demonstrates  when  the  participants  jom  the  process  (Brucker  1995). 


Figure  2.  Design/construction  process  of  Military  Construction,  Arniy. 
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Table  1-  Participants,  responsibilities;  and  products  of  Military  Construction,  Army  process. 


I  Participants 


Responsibilities 


Products  /  Documents 


Department 
of  the  Army 
(DA),  Office 
of  Chief 
Engineer 
(OCE), 
MACOM 

Functional  and  Capability  Planning  Analysis 
Prioritize  Projects 

Request  Funding  Authorization  from  Congress 
Manage  Design  and  Construction  Program 
Update  Design  and  Construction  Requirement 

5  Year  Defense  Program 

Army  Stationing  and  Installation  Plan 

Long  Range  Construction  Program 

Owner/User 

installation 

Identify  Training  and  Facility  Requirements 
Evaluate  and  Select  Site 

Assess  Environmental  Impact 

Determine  Functional  and  Technical 
Requirements 

Design  Review  and  Approval,  User  Changes 
Construction  Coordination,  Acceptance 

Installation  Master  Plan 

Real  Property  Requirements 

Environmental  Impact  Statement  (if  required) 

Detailed  Site  Plan 

Architectural  Program  (Functional/Technical 
Requirements) 

FORM  1 391 ,  Cost  Estimate  (Scope  and  Budget) 
ARMS  (Automated  Review  Management  System) 

District  or 
Division 

Request  Funding  Approvals  for  Programming, 
Design  and  Construction 

Develop  Architectural  Program  (Functional/ 
Technical  Requirements)  or  Hire/VE  Firm 
Select  A/E  and  Negotiate  (Design) 

Coordinate  Design,  Review  and  Approval 

Bid  &  Select  Contractor  (Construction) 

Expedite  Materials,  Manage  Public  Relations 
Close-out  Project  (After  Construction) 
Manage  Public  Relations 

/Architectural  Program  (Functional/Technical 
Requirements) 

Design  Reviews/Construction  Changes 

Design  and  Construction  Contracts 

Project  Management  Plan,  Upward  Reports 

ARMS  (Automated  Review  Management  System) 

Design 

Agency 
(Corps  or 
A/E  Firm) 

i 

Prepare  Design  and  Engineering  Analysis 
Prepare  Concept  and  Final  Design/Changes 
Prepare  Construction  Documents, 

Specifications 

Cost  Estimate,  Value  Engineering  1 

Review  Shop  Drawings 

Analyze  Life  Cycle  Costs 

Working  Drawings 

Specifications 

Design  Analysis 

Detailed  Cost  Estimate 

Design  Changes  During  Construction 

ARMS  (Automated  Review  Management  System) 

Resident  Review  &  Approve  Payment  Requests 

Engineer  Negotiate  Change  Orders 

Assure  Contractor  Quality 
Review  Submittals,  Materials,  Shop  Drawings 
Assure  Customer  Satisfaction 
Review  &  Analyze  Contractor's  Progress 
Prepare  Correspondence 
Monitor  Contractor's  Safety  Program 
Collect  As-Builts,  Warranties,  O&M  Manuals 
Identify  Trends/Lessons  Learned 
Site  Coordination 

Prepare  A/E  &  Contractor  Evaluations 
_ Review  Biddability  Constructibility  Operability 


General  Perform  Contract  According  to  Plans  & 
Contractor  Specifications,  Manage  Site,  Labor,  Equipment, 
Materials,  Time,  and  Subcontractors.  Document 
Construction  Progress,  Changes,  Quality, 
Safety,  and  Others. 


Contract  Plans  and  Specifications  with  Modifications, 
Construction  Progress  Reports,  Site  Layout, 
Schedule  Approval,  Payment  Estimates,  QA/QC 
Plan,  Critical  Materials/Status,  Actual/Anticipated 
Delays,  Record  Drawings,  Safety  Records,  i 
Claims,  Funding  Status,  QA/QC  Reports,  Signifi-  I 
cant  Deficiency  Action  Plan,  Submittal  Registers, 
Shop  Drawings,  Accident  Prevention  Plan,  Envi¬ 
ronmental  Control  Plan,  Certified  Payroll  Register, 
Affirmative  Action  Plan,/VE  &  Contractor  Perfor¬ 
mance  Evaluation,  Project  Meeting  Minutes 
(Prebid,  Preconstruction,  Construction  Quality 
Control/ Assurance),  ARMS  (Automated  Review 
Management  System) 


Preliminary  Schedule,  Cost  Estimate,  Site  Layout 
Progress  Reports,  Payment  Request,  QA/QC 
Reports,  Schedule  Update,  Request  for  Information, 
Major  Resource  Schedule,  Samples/Certlfication/Test 
Results,  Warranties/Operational  Manuals,  As-built 
Drawing  Update  (contract-specific),  Shop  Drawings, 
Safety  Plan  and  Records,  Daily  Manpower  and 
Minority  j 
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The  Corps  of  Engineers  follows  a  traditional  Design-Bid-Build  approach  for  most 
facilities.  This  process  is  defined  in  a  Corps  of  Engineers  regulation  (Ihchnical 
Manual  5-800-2)  and  follows  a  conunon  approach  to  facility  design  for  commer¬ 
cial  construction.  It  is  very  similar  to  the  process  defined  in  the  AIA  Architect’s 
Handbook  of  Professional  Practice  (AIA  1987).  The  AIA  dociunent  breaks  the 
design  phases  of  the  process  into  three  distinct  parts:  Schematic  Design  (0  to 
10%),  Design  Development  (11  to  35%),  and  Construction  Dociunents  (36  to 
100%).  The  Corps  of  Engineers  limits  the  phases  officially  to  Concept  (0  to  35%) 
and  Final  Design  (36  to  100%);  however,  they  generally  break  the  process  into 
the  three  parts.  In  general,  the  processes  are  very  similar  and  major  review 
nulestones  are  at  the  completion  of  10,  35,  60  (for  Air  Force  work)  and  95  per¬ 
cent.  The  review  process  includes  a  Biddability,  Constructability  and  Operability 
(BCO)  review,  which  is  conducted  by  Corps  construction  and  facility  operation 
personnel  to  minimize  problems  dxuing  bidding,  construction,  and  operation. 

The  Construction  Dociunent  process  consumes  the  greatest  amount  of  timp  and 
resomces,  which  leaves  very  little  time  for  the  designer  to  anEtlyze  designs,  check 
alternatives,  and  negotiate  conflicts  with  other  design  disciphnes  during  the 
schematic  design  phase.  A  constant  need  exists  for  reviews  and  backcheck  re¬ 
views  during  the  construction  document  phase.  Automating  these  reviews  and 
moving  them  forward  to  the  programming  and  schematic  phases  would  enable 
the  designers  to  define  a  better  scope  for  the  building  program,  allow  them  to 
check  several  design  alternatives,  and  provide  the  time  for  them  to  conduct  de¬ 
sign  analysis  (energy,  life  safety,  value  engineering,  roofing  systems).  Analyses 
such  as  these  are  usually  conducted  on  only  large  building  programs.  The  ability 
to  move  these  analyses  forward  in  the  process,  and  to  perform  them  on  aU  budd¬ 
ing  programs,  would  improve  the  overall  quality  of  the  buildings  and  the  integra¬ 
tion  of  its  systems.  In  proposing  a  new  process  to  be  implemented  in  the  colla¬ 
borative  engineering  environment,  USACERL  took  these  factors  into  account. 

Format  of  Design  Information  Produced 

A&E  firms  and  Army  Corps  of  Engineers  technical  personnel  are  using  CAD 
systems  and  related  technologies  to  develop  design  drawings,  conduct  engi¬ 
neering  analyses,  and  write  specifications  used  during  construction.  Many  Corps 
projects  must  be  submitted  in  CAD  format.  The  web  site  at  the  U.S.  Army 
Engineer  Waterways  E3q)eriment  Station  (WES)  in  Wcksburg,  MS,  has  links  to 
the  following  standards  (IH-Service  CADD/GIS  Technology  Center  97): 


Spatial  Data  Standards 

AEC  CADD  Standards  (Version  1.4) 

AE  Deliverables 
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•  CADD  Details 

•  Productivity  Enhancement  Utilities  for  AutoCAD  and  MicroStation. 

Some  test  projects  are  even  being  distributed  for  bid  on  CD-ROMs  as  part  of  the 
Electronic  Bid  Set  effort  (Tri-Service  Solicitation  Network  1997).  Potential 
bidders  can  request  the  bid  set  CD-ROM  and  then  print  any  drawings  needed  to 
complete  the  bid  package.  They  can  also  use  software  tools  to  automate  the 
quantity  takeoff  procedure.  While  it  takes  more  effort  to  save  all  the  dravsdng 
and  specification  files  to  a  CD-ROM  for  bids,  the  Corps  of  Engineers  has  reduced 
printing  costs  significantly.  Amendments  to  the  bid  set  are  issued  on  diskette  or 
via  the  Internet.  (U.S.  Army  Corps  of  Engineers  8/14/96)  (http-y/tsn.wes.army. 
mil/ProjectHomePage.htm). 

Current  Construction  Process 

Figure  4  shows  the  Current  Construction  Process.  Contractors  manage  and 
perform  construction,  while  Corps  Resident  Engineers  approve  work  plans  and 
manage  changes  and  modifications,  progress  payments,  requests  for  information, 
construction  quality  assurance  plans,  close-out  and  warranties,  and  also  ensure 
all  as-built  information  is  collected  by  the  contractor.  Resident  Engineers  have  a 
key  role  in  conducting  BCO  reviews  on  projects  during  design.  They  provide 
designers  with  practical  construction  expertise  and  lessons  learned  so  that 
potential  problems  can  be  avoided  or  minimized  (USACE  1990). 

Format  of  Construction  Information  Produced 

Even  if  the  project  is  designed  using  CAD,  most  construction  personnel  are 
unable  to  take  advantage  of  the  information  represented  electronically  in  CAD 
drawings  and  databases.  The  CAD  files  and  databases  created  during  design 
and  documentation  are  typically  printed  and  used  as  hardcopy  dravnngs  during 
construction.  Unless  the  construction  contract  specifically  requires  the  con¬ 
tractor  to  update  the  CAD  fides,  the  as-built  drawings  turned  over  to  the  owner 
will  be  marked  up  paper  drawings.  Many  Resident  Engineers  use  the  Resident 
Management  System  (RMS)  to  support  their  daily  project  management  tasks 
(Barker  1991).  RMS  supports  construction  management  at  the  Resident  Engi¬ 
neer  level,  including  project  planning,  contract  administration,  quahty  assur¬ 
ance,  payments,  correspondence,  submittal  register,  safety  and  accident  admini¬ 
stration,  and  modification  processing  and  management  reporting  capabilities 
(USACE  1993).  A  decision  on  deployment  of  RMS  is  scheduled  for  4*  Quarter 
FY97  (USACE,  Jime  1997,  Commander’s  IRM  Smart  Book,  available  to  Corps 
only,  in  PDF  format). 
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The  use  of  CAD  applications  and  related  technologies  during  construction  can 
result  in  improved  communication  between  design  and  construction  personnel 
(Chin  1995).  Construction  supervisors  who  have  access  to  CAD  drawings  and 
databases  could  find  needed  information  quickly  and  easily,  and  would  be  able  to 
look  at  any  building  section,  detail,  or  work  area  that  was  being  discussed.  This 
accessibility  could  help  reduce  design  deficiencies,  change  orders,  and  increase 
productivity,  which  are  affected  by  problems  in  communication  during  design 
and  construction  (Stumpf  1994).  Construction  inspectors  would  be  able  to  select 
a  building  component  or  performance  feature  and  pull  up  quality  control/quality 
assurance  (QC/QA)  checklists  if  the  CAD  drawings  were  associated  with  relevant 
databases  (Chu  1995).  In  the  fizture,  an  object-oriented  CAD  model  of  the 
building  could  be  linked  to  project  control  software  such  as  RMS  and  used  to 
capture  and  analyze  progress  information  during  construction  (Stumpf,  August 
1995). 


S| 

I 


51 


t  Procurement  j  |  Subcontracting 

1  Project  Monitorine/Cotttrol 

—  — • 

I 

1  Getpermhs 

oversee 

startup/testittg 

Request  pbut 

ofmoUlizatioii 

areas: 

owork  areas 


Materials  Expediting 
•  ensure  that  materials 
I  are  ordered  and 
ddivered  iasnfiidtent 
time  to  avoid  ddays 


project  and 
safety  signs 


-  changes  and  modifications 
>  progress  payments 

.  construction  quality  assurance  (CQC) 

-  ensure  record  drawings  reflect  as-built  conditions 
-contractor  performance  evaluation 

-closeout  and  warranties 


request 

punchlist 


Get  permits 


site  layout 
drawings 


jEnsnre  | 

documentation 
of  all  as4}ullt  anq 
other  info,  for  O  4  M 
(punchlist) 


[Post  Completion 
A/E  evaluation 


Contract  administration  I  Milestones  and  project  meetings 

I  Coordinate  design  changes 

Provide  reports 
Arrange  fortesting 


track  qwnt  cost 


‘  Manage  progress 
'  payments 


provide  input 
insitebtyont 


Cash  flow  num^^ent 


provide  dates  for 
matpial  requirement 


Detailed  process  planning  with  equipment 
Update  schedule  with  progress 


•  oLiqrant  drawings 

•  ^op  drawings 

•  dtn^  orden  and  modifkation  padc^es 
-progress  reports 

-  partial/final  contract  payment  estimates 

-  record  (as-built)  drasnngs 


•  O&M  instructions 
-submittals 
-  testing  records 
-samples 

-  post  completion  evaluation 


Figure  4.  Current  construction  process. 
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Accuracy  of  facility  drawings  and  records  required  by  the  using  agency,  facility 
manager,  and  O&M  personnel  is  another  area  that  needs  improvement.  As-built 
drawings  and  building  component  information  are  usually  transferred  to  the 
facility  user  on  paper.  Some  projects  now  require  that  the  contractors  provide 
accurate,  updated  CAD  as-built  drawings.  However,  these  CAD  as-builts  are  not 
typically  linked  to  a  database  of  detailed  component  information.  The  effective 
use  of  CAD  or  object-oriented  CAD  technologies  to  create  accurate  as-built 
drawings  linked  to  data  on  actual  building  components  would  provide  an  elec¬ 
tronic  representation  of  the  facility  which  would  be  useful  throughout  the  life  of 
the  facility. 

Tb  understand  how  CE  can  be  used  in  a  reengineered  facility  design  process,  a 
study  of  the  traditional  design  process  was  necessary.  Focusing  on  the  strengths 
and  weaknesses  of  both  CE  and  the  traditional  facility  design  process,  a  proto- 
tj/pe  collaborative  design  process  was  developed  for  experimental  purposes. 

Using  Collaborative  Engineering  To  Support  an  Improved  Facility 
Design  Process 

Introduction 

The  focus  of  this  section  will  be  to  document  improvements  in  the  facility 
delivery  process  that  can  be  gained  from  the  development  and  use  of  CE.  A 
facility’s  life-cycle  process  usually  begins  with  a  requirement  for  a  new  building 
or  additional  space  and  ends  with  demolition  or  recycle.  The  traditional  A/E/C 
delivery  process  consists  of  several  stages:  requirements  analysis,  funding 
analysis,  schematic  design,  conceptual  design,  final  design,  procurement,  con¬ 
struction,  and  O&M.  Collaborative  engineering  is  a  new  way  of  doing  business 
that  uses  automation  technology  to  support  reengineered  A/E/C  delivery 
processes.  Collaborative  engineering  is  similar  in  approach  to  that  of  concurrent 
engineering.  Concurrent  engineering,  mostly  used  in  manufacturing,  relies  on 
concurrent  or  parallel  design  processes,  whereas  CE  in  the  A/E/C  domain  focuses 
on  serial  or  sequential  design  processes. 

With  a  CE  approach,  it  is  estimated  that  the  Corps’  facihty  delivery  time  will  be 
decreased  by  50  percent  and  the  resulting  facilities  will  be  more  useful  and 
efficient  throughout  their  life  cycle.  With  CE  technology,  it  will  be  possible  to 
produce  80  percent  of  construction  documents,  save  3  to  9  percent  of  the  con¬ 
struction  costs,  and  reduce  facility  delivery  time  from  551  to  115-214  workdays. 
As  a  conservative  estimate,  well-designed  bmldings  will  use  25  to  35  percent  less 
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energy  for  heating  and  cooling  during  their  life  cycle.  Technology  utilization 
during  the  O&M  and  facility  management  phase  is  expected  to  result  in 
significant  savings  and  improved  decisionmaking  affecting  the  $94  billion  DOD 
O&M  budget  and  $14  billion  backlog  of  maintenance.  During  the  construction 
phase,  CE  will  improve  coordination  of  trades  and  assist  project  managers  in 
analysis  and  optimization  of  construction  schedules.  As-built  models  updated 
during  construction  will  be  used  directly  by  engineered  management  systems  to 
optimize  maintenance  funding  plans  and  schedule  work  costs  effectively. 
CAFMS  systems  will  also  be  able  to  use  these  models  to  assign  space  and  track 
inventory.  The  same  models  cein  be  reused  during  retrofit  design  to  modify  the 
use  of  facilities. 

Business  Process  Reengineering 

Hammer  and  Champy,  authors  of  the  much  noted  Reengineering  the  Corporation: 
A  Manifesto  for  Business  Revolution,  define  reengineering  as  “the  fundamental 
rethinking  and  radical  redesign  of  business  processes  to  achieve  dramatic 
improvements  in  critical,  contemporary  measures  of  performance,  such  as  cost, 
quahty,  service  and  speed.”  Business  process  reengineering  (BPR)  has  rapidly 
developed  towards  a  new  management  philosophy,  based  on  predecessors  b'kp 
TQM,  Overhead  Value  Analysis,  Kanban  or  Just-In-Time  Management.  BPR 
stresses  the  radical  change  of  processes.  However,  the  redesign  of  processes  is 
only  one  aspect  of  the  management  of  business  processes.  Dr.  Kutschker  (1995) 
writes  that  at  least  three  different  kinds  of  process  management  can  be 
identified:  the  management  of  ongoing  business  processes,  the  improvement  of 
business  processes,  and  the  reengineering  of  business  processes. 

The  management  of  business  processes  includes  their  continuous  improvement, 
but  the  fact  that  managers  are  usually  responsible  only  for  functions  and 
departments  and  not  for  processes  crossing  functions  or  departments  hinders 
this  improvement.  In  most  cases,  managers  isolate  parts  of  a  business  process 
by  focusing  on  their  department  only,  which  usually  resvilts  in  a  suboptimal 
solution  in  the  improvement  of  a  process  (Kutschker  1995). 

BPR,  as  a  concept,  is  valid  because  it  calls  for  process  reevaluation  using  an 
analysis  that  questions  both  the  need  for  the  design  and  its  process.  This  radical 
concept  is  exactly  what  forces  companies  to  implement  it  only  in  a  piecemeal 
approach.  The  idea  of  total  transformation  is  abandoned.  Although  periodic 
reevaluation  and  redesign  of  business  processes  are  valuable  managerial  and 
strategic  tools,  it  is  not  enough  vdth  reengineering,  which  stresses  a  need  to 
“obliterate”  and  recreate  (Geisler  1996). 
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Since  reengineering  involves  such  a  radical  change,  it  is  not  a  tool  to  be  used 
lightly.  Hammer  and  Champy  recommend  that  organizations  apply  it  at  the 
lowest  level  of  their  microprocesses.  The  basic  principles  (Rinni  1994)  of 
reengineering  that  Hammer  and  Champy  recommend  are; 

1.  Organize  work  around  outcomes,  not  tasks. 

2.  Design  processes  that  can  be  accomplished  by  as  few  employees  as  possible. 

3.  Charge  those  who  will  use  the  output  of  a  process  with  performing  it. 

4.  Build  decisionmaking  and  interned  control  into  the  process. 

5.  T.ir>k  parallel  activities  and  perform  them  concurrently  whenever  possible. 

In  the  past  several  years,  reengineering  fever  has  swept  corporate  America,  but 
the  vast  majority  have  found  that  it  has  not  been  the  magic  cure  for  which  they 
had  hoped.  Why  is  reengineering  failing  to  live  up  to  its  promise?  According  to 
some  management  experts,  managers  are  to  blame.  Champy  and  others  contend 
that  the  problem  is  that  managers  often  pay  lip  service  to  the  effort  but  are  not 
behind  it.  They  are  threatened  by  the  loss  of  power.  They  do  not  display  leader¬ 
ship  and  commitment,  do  not  change  their  behavior,  and  do  not  act  as  role 
models.  These  are  some  of  the  reasons  that  TQM,  continuous  improvement,  and 
empowerment  have  failed  in  many  organizations.  Mandrish  and  Schaffer  (1996) 
believe  that  these  are  not  the  reasons  reengineering  efforts  usually  do  not 
succeed.  They  beheve  the  “real  problem  lies  with  the  essence  of  the  reengi¬ 
neering  methodology  itself.  The  radical  all-or-nothing  approach  of  reengineering 
is,  for  most  companies,  impractical  and  unworkable.” 

When  the  goal  is  to  dramatically  increase  process  speed,  technology  will  almost 
always  play  a  pivotal  role,  but  automation  is  not  the  goal  of  reengineering. 
When  deployed  strategically,  reengineering  can  fulfill  management’s  short-  and 
long-term  goals  by  redesigning  critical  core  processes,  and  by  synchronizing  the 
organizational,  individual,  and  cultural  aspects  of  operations.  Just  as  strategy 
seeks  to  optimize  an  organization’s  response  to  change,  reengineering  seeks  to 
understand  rhauging  customer  needs  and  wants,  and  then  shape  operations  to 
respond  to  those  changes  in  support  of  strategy”  (Manganelli  and  Raspa  1995). 


New  information  technologies  and  automation  will  have  an  impact  on  the  coordi¬ 
nation  of  business  relations.  New  technologies  such  as  electronic  mail,  corporate 
and  public  databases,  application  systems,  fax,  video  and  computer-conferencing, 
are  considered  to  be  some  of  the  driving  forces  of  internationalization  (Kutschker 
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1995).  Even  though  the  strategic  importance  of  information  technology  is 
necessary,  few  studies  closely  investigate  the  relationship  between  state  of  the 
art  applications  zind  their  impact  and  importance  for  coordinating  dispersed 
activities  and  business  processes. 

Daniel  Btirrus  (1993)  describes  how  to  use  technology  to  go  beyond  the 
competition.  He  discusses  20  core  technologies,  tiheir  relationship  to  24  new 
tools,  and  9  ways  these  tools  will  revolutionize  our  lives.  The  keys  to  success 
when  reinventing  government  and  business  are  “anticipation,  integration, 
flexibility,  communications  and  orchestration.”  He  describes  how  to  go  beyond 
the  competition  by  rmderstanding  what  the  new  technologies  and  tools  are,  and 
how  to  revolutionize  the  delivery  system  of  products  and  services,  the  ways  in 
which  we  communicate,  accept  and  use  computers,  and  internalize,  imderstand 
and  use  massive  amoimts  of  data.  He  explains  how  several  companies 
drastically  shortened  their  design  and  development  process  (“leverage  time  with 
technology”)  by  using  supercomputers  and  networked  computers.  Companies 
need  to  “enter  the  corommiication  age,”  by  learning  how  to  collect  digital 
information  in  a  focused  and  structured  way  so  it  is  linked  to  other  relevant 
information.  Users  would  then  be  able  to  access  information  needed  to  take 
action. 

Blackinston  (1996)  writes  that  “In  a  sense  we  are  emerging  from  the  Dark  Ages 
of  U.S.  business  —  the  period  firom  1950-1980  —  when  managers  believed  in 
short-term  results,  shaving  costs,  focusing  on  finance  and  marketing  rather  than 
products  and  processes,  and  making  deals  instead  of  serving  the  customer.”  In 
the  Juran  Institute’s  view,  10  trends  have  emerged  as  a  result  of  the  TQM  effort 
(Blackinston  1996).  One  of  these  trends.  Information  and  Analysis,  directly 
relates  to  the  use  of  CE  in  support  of  the  facility  design  process.  The  Informa¬ 
tion  and  Analysis  trend  emphasizes  measmement  and  information  as  key  ele¬ 
ments  of  any  organization’s  infrastructure.  Information  systems  are  also  a  key 
part  of  the  infrastructure  of  TQM  and  reengineering.  Information  can  be  used  to 
improve  the  next  generation  of  products,  improve  business  processes,  reduce 
time  cycles,  improve  distribution,  improve  field  service,  better  imderstand  the 
needs  of  customers,  and  design  products  and  services  to  meet  these  needs. 

Collaborative  Engineering 

CE  is  a  new  way  of  doing  business  that  uses  information  technology  to  support 
reengineered  A/E/C  dehvery  processes.  CE  is  similar  in  approach  to  concurrent 
engineering  (mostly  used  in  the  manufactiuing  area)  which  relies  on  concurrent 
or  parallel  design  processes.  CE  in  the  A/E/C  domain,  however,  focuses  on  serial 
or  sequential  design  processes.  Krajewski  and  Ritzman  (1996)  define  concurrent 
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engineering  “(or  sometimes  simultaneous  engineering  or  interactive  design),  as  a 
process  where  design  engineers,  manufacturing  specialists,  marketers,  buyers, 
and  quality  specialists  work  jointly  to  design  the  product  or  service  and  select 
the  production  process  ”  Collaboration  involves  commxmication  and  negotiation 
between  A&E  teams  at  distributed  sites  as  design  activities  or  subtasks  are 
performed.  Collaboration  technology  supports  the  needed  communication. 
“However,  different  couplings  between  subtasks  place  different  demands  on  the 
level  of  communication  which  must  be  provided  by  the  collaboration  technology 
of  a  concurrent  engineering  environment”  (Case  and  Lu  1996). 


Improvements  in  the  facility  design,  construction,  and  O&M  processes  can  be 
achieved  through  the  development  of  a  CE  framework  that  supports  distributed 
virtual  engineering  teams,  intelligent  engineering  models,  and  automated  cap¬ 
ture/reuse  of  corporate  knowledge. 

Distributed  virtual  engineering  teams  are  geographically  and  organizationally 
dispersed  engineers,  architects,  and  related  design  professionals  working  on 
projects  as  if  they  were  collocated.  Current  “web-based”  and  workflow  solutions 
are  essentially  advanced  document-based  management  systems  that  share  infor¬ 
mation  in  an  unstructured  way  that  does  not  support  engineering  usage.  In 
other  words,  the  documents  can  be  shared  over  the  network,  but  the  computer 
has  no  idea  what  is  in  them. 

The  CAD  industry  has  finally  advanced  to  the  point  at  which  it  is  possible  to 
construct  object-oriented  models  of  facilities  and  it  is  actively  working  on  object 
standards  for  those  models  (i.e.,  lAI  and  Standard  for  the  Exchange  of  Product 
Models  [STEP])  (lAI  1997).  Intelligent  engineering  models  being  developed  are 
explicit  and  computable  representations  within  specific  domains  that  work 
together  to  form  a  comprehensive  facility  model.  These  models  must  be  designed 
to  last  over  the  life  cycle  of  a  facihty,  typically  10  to  50  years  after  construction. 

Finally,  as  collaborative  and  concurrent  engineering  become  realities,  the  auto¬ 
matic  capture  and  reuse  of  A/El/C  and  O&M  information  can  be  incorporated  into 
coiporate  knowledge  bases  for  use  in  future  designs.  Whth  this  corporate  know¬ 
ledge,  resxilting  facilities  will  be  more  useful  and  efficient  throughout  their  life 
cycle. 

Change  management.  One  school  of  change  management  argues  that  old  prac¬ 
tices  must  be  “obliterated”  and  new  processes  designed  from  scratch  to  fully 
leverage  new  technologies  and  business  realities.  In  practice,  few  managers 
have  the  luxury  of  redesigning  their  processes  or  organizations  from  a  “clean 
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sheet  of  paper”  —  people,  equipment,  and  business  knowledge  cannot  be  so 
easily  scrapped.  However,  some  types  of  organizational  change  are  riskier  if 
undertaken  piecemeal  or  incrementally.  Change  managers  do  not  always  recog¬ 
nize  interdependencies  among  technology,  practice,  and  strategy  (Brynjolfsson, 
Renshaw,  and  Alstyne,  1997).  “Downsizing  is  an  American  reality”  (Hubiak  and 
ODonnel  1997).  The  underlying  assumption  forcing  the  need  for  downsizing  is 
the  belief  that  there  are  excess  jobs  within  the  organization  and  that  elimination 
of  these  jobs  will  improve  the  organization’s  effectiveness  and  efficiency  without 
hindering  its  competitive  advantage.  Hubiak  and  O’Donnell  (1997)  say  that  over 
8  million  people  lost  their  jobs  to  downsizing  in  U.S.  organizations  between  1980 
and  1993.  Layoffs  averaged  3,106  persons  per  day  in  1994  and,  although  reduc¬ 
tions  slowed  somewhat  during  1995  and  1996,  many  large  organizations  such  as 
AT&T,  Boeing,  and  BellSouth  are  still  cutting  back. 

Reengineering  is  not  easy,  inexpensive,  or  speedy.  Hammer  and  Champy  wrote 
that  reengineering  an  entire  corporation  can  be  a  10-yr  process,  which  is  why  a 
commonly  quoted  statistic  states  that  70  percent  of  reengineering  efforts  fail 
within  5  years  (Kinni  1994).  Hammer  and  Champy  are  now  stressing  several 
key  ideas. 

First,  reengineering  is  done  in  a  deep  cultural  context,  those  things  an 
organization  values,  believes  and  rewards.  Second,  more  attention  must  be 
paid  to  the  issue  of  people.  The  changing’  covenant  with  workers  means  that 
if  an  orgaDization  can  do  more  with  less,  even  a  good  worker  may  be  let  go. 

Last,  when  an  enterprise  reengineers,  it  becomes  mare  people-intensive,  not 
less  —  a  realization  at  cross-purposes  with  the  old  idea  of  automation  as 
worker  reduction.  Reengineering  gives  workers  accountability,  thus  increas¬ 
ing  an  organization’s  dependability  on  people  (Ettorre  1995). 

Steven  Kensinger  (1996)  wrote  “When  studying  the  volumes  of  books  by  manage¬ 
ment  gurus,  engineering  and  the  design  process  are  conspicuous  by  their 
absence.”  Most  business  experts  focus  on  general  business  processes.  Kensinger 
describes  the  design  engineering  process  as  a  unique  race  similar  to  an 
endurance  nm  through  an  uncharted  obstacle  course.  Successful  design  teams 
have  most  of  the  key  elements  for  success:  elements  of  cross-functional  team¬ 
work,  agreeing  to  disagree,  hands-on  approaches,  spending  time  with  customers, 
tolerance  of  failure,  and  following  the  product  from  birth  to  death.  When  the 
infoimal  communication  and  cooperation  networks,  which  are  vital  to  performing 
engineering  tasks,  are  disturbed  during  restructuring,  product  development  is 
affected.  (This  effect  was  described  ia  Doron  Levin’s  book.  Irreconcilable 
Differences.)  The  early  introduction  of  computer  tools  left  some  designers 
struggling  to  figure  out  the  technology  while  still  doing  their  regular  jobs.  As 
designers  learned  how  to  use  computer  tools,  a  new  design  process  emerged 
based  on  the  computer  tools  rather  than  the  product  requirements.  To  achieve 
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the  true  potential  of  computer-based  engineering  tools,  Kensinger  stresses  that  a 
technology-assisted  design  process  can  be  built  that  uses  computer  tools  while 
allowing  the  user  to  focus  on  the  product  being  designed. 

Therefore,  the  premise  behind  the  development  of  computer-based  engineering 
tools,  that  automation  and  technology  can  replace  the  downsized  and  reduced 
resources  in  DOD  is,  according  to  Hammer  and  Champy,  a  fallacy.  DOD  may  end 
up  depending  more  on  their  people.  So  what  is  the  alternative?  One  way,  as 
recommended  by  Mandrish  and  Schaffer  (1996),  is  through  results-driven  process 
redesign. 

Results-driven  process  redesign.  The  restilts-driven  process  redesign  approach 
uses  many  elements  of  reengineering,  but  blends  them  into  a  continuous 
improvement  approach.  The  foundation  of  this  approach  is  to  redesign  the 
process:  (1)  with  a  focus  on  results,  (2)  in  a  way  that  involves  all  the  key  players 
in  the  redesign  process,  and  (3)  incrementally,  rather  than  attempting  to 
redesign  everything  at  once.  This  approach,  along  with  the  use  of  CE  tech¬ 
niques,  is  most  likely  the  best  approach  to  improving  the  facility  design  process. 
The  foundation  of  the  facihty  design  process  is  too  large  and  involves  too  many 
legacy  processes  to  totally  reengineer. 

The  seven  steps  (Mandrish  and  Schaffer  1996)  involved  in  the  results-driven 
process  redesign  are: 

1.  Identify  the  most  urgent  business  performance  improvements  needed  by  the 
organization,  and  be  clear  on  the  specific  improvement  in  restdts  that  are 
needed. 

2.  Identify  the  one  or  two  business  processes  that  most  need  to  be  changed  to 
help  achieve  the  key  performance  improvements. 

3.  Identify  all  the  key  stakeholders  in  the  process,  including  those  whose  jobs 
will  likely  change  as  a  result  of  a  redesign. 

4.  Form  a  team  from  among  these  stakeholder  groups  and  give  the  team  the 
assignment  to  not  just  make  recommendations  but  to  actually  implement 
changes  immediately  that  will  achieve  the  desired  results. 

5.  Have  the  team  work  quickly  to:  gather  any  required  data,  map  the  process, 
design  the  needed  improvements  that  will  meet  the  goal,  and  get  the 
necessary  input  or  approvals  to  enable  action  to  be  launched. 
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6.  Implement  the  changes. 

7.  Monitor  implementation  and  results,  and  introduce  supporting  changes  in 
systems  or  infrastructure  as  needed.  Then  use  the  initial  successes  as 
learning  experiences  for  laimching  the  next  wave  of  process  redesign  efforts. 

Substantial  savings  could  be  realized  by  placing  more  emphasis  on  optimizing 
the  facihty  design  process.  A  fully  implemented  collaborative  software  environ¬ 
ment  could  significantly  improve  the  quahty  of  decisionmaking,  contract  docu¬ 
mentation,  and  related  imcro-design  processes.  Through  collaborative  tech¬ 
nology,  extended  design  groups  work  as  a  coordinated  team,  and  software  assists 
designers  in  making  optimal  decisions  through  improved  information  dissemi¬ 
nation  and  conflict  management.  Designers  have  the  capability  to  effectively 
consider  a  wider  variety  of  design  solutions  and  evaluate  additional  edtematives 
to  improve  the  quality,  constructibility,  energy  efficiency,  and  life-cycle  cost 
effectiveness  of  the  facility.  Improved  communications  via  the  Internet  and  CE 
environments  can  enable  interdisciplinary  multi-organizational  design  teams  to 
effectively  collaborate  throughout  the  facility  design,  construction,  and  use  of  a 
building. 

Reengineered  Design  Process  in  a  CE  Environment 


The  following  proposed  reengineered  facility  design  process  (Figure  5)  demon¬ 
strates  how  improved  information-sharing  capabilities  and  conflict  management 
during  collaborative  design  enables  a  team  to  resolve  design  issues  and  conflicts 
earlier  in  design  development.  This  sharing  of  information  could  result  in  an 
improved  facility  design,  fewer  errors  and  omissions,  and  better  interdisciplinary 
coordination  of  design  goals  and  building  systems.  Figure  5  shows  how  design 
mformation  evolves  in  the  testbed’s  CE  environment. 


information  Evolution  in  a  CE  Environment 


Figure  5  also  shows  how  design  information  evolves  in  the  testbed’s  CE  environ¬ 
ment.  The  Expanding  Facility  Model  illustrates  how  a  building’s  design  infor¬ 
mation  increases  throughout  the  process  of  design.  Once  the  facility  is  handed 
over  to  the  owner  the  facility  model  becomes  Corporate  Knowledge.  This  know¬ 
ledge  can  be  used  for  future  designs,  operations  and  maintenance  activities,  and 
building  management. 
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Figure  5.  Design  information  evolution  in  a  CE  environment. 


Instead  of  following  the  traditional  design  process,  the  evolution  process  empha¬ 
sizes  how  the  documentation  stage  of  design  can  be  reduced  to  allow  more  time 
for  design  development  and  detailed  design.  Conflict  management  and  infor¬ 
mation  sharing  during  these  earlier  design  stages  reduce  changes  in  the 
documentation  and  construction  stages.  The  reduction  of  cheinges  and  modifi¬ 
cation  during  construction  can  greatly  reduce  the  time  and  cost  of  construction. 

As  shown  in  Figure  5,  throughout  the  different  stages  of  design,  design  informa¬ 
tion  evolves,  increasing  the  size  of  the  facility  model.  During  the  schematic 
design  stage,  designers  pull  design  information  from  corporate  knowledge  and 
the  building  hbrary  and  instantiate  or  create  their  new  design.  Once  the  design 
reaches  a  certain  stage  and  the  designers  would  like  analysis  and  feedback  from 
other  project  participants,  they  can  broadcast  £ind  receive  each  other’s  design 
information.  While  in  the  design  development  stage,  design  information  is  being 
refined  or  further  analyzed.  Detailed  design  requires  designers  to  elaborate  and 
finalize  their  design.  Documentation  is  expedited  by  developing  documentation 
standards  which  can  be  analyzed  and  used  to  extract  information  during  the 
automatic  generation  of  construction  documents  (Griffith  1996).  During  con¬ 
struction  and  occupancy,  the  facility  design  information  can  be  collected  and  used 
to  manage  the  as-planned  and  as-built  facility  model  (Brucker  and  Stumpf  1996). 
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3  Testbed  Technology 


The  testbed  supports  teaming  by  using  a  distributed  object-oriented  database, 
called  the  \^irtual  Workspace  System  (VWS)  (Heckel  et  al.  1997).  The  Agent 
Collaboration  Environment  (ACE)  uses  VWS  to  broadcast  changes  to  shared 
design  information  (centered  upon  an  object-oriented  representation)  between 
team  members.  The  information  exchange  between  these  two  systems  is  accom¬ 
plished  iiHiTig  \^rtual  Workspace  Language  (VWL),  which  incorporates  the 
Knowledge  Intercheinge  Format  (KIF)  and  the  Knowledge  Query  and  Manipu¬ 
lation  Language  (KQML). 

The  testbed  uses  a  virtual  teaming  architectxire  centered  around  a  distributed 
object-oriented  representation  of  the  design  and  process  information.  A  testbed 
library  representation  has  been  developed  to  provide  a  shared  set  of  concepts 
(ontology)  which  facilitates  the  creation  of  objects  and  communication  of 
information.  This  representation  contains  both  product  and  process  information. 
By  providing  process  information,  this  representation  allows  sophisticated 
project  management  and  the  development  of  construction  plans.  Agents  that  use 
this  shared  representation  have  been  developed  for  project  management, 
architectural  layout,  code  checking,  mechanical/energy  analysis,  construction 
planning,  roof  design,  and  O&M.  Legacy  tools  such  as  CAD  have  also  been 
integrated  into  the  system.  The  following  sections  describe  the  components  of 
the  testbed  demonstration  which  enable  the  creation,  manipulation,  utilization, 
and  communication  of  information  about  a  facility  design. 


Agent  Collaboration  Environment 

An  agent-based  software  environment  developed  at  USACERL,  ACE  is 
specifically  designed  to  support  the  delivery  and  sustainment  of  facilities  (Hoff 
1995).  Conciurent  Persistent  ACE  (CPACE)  is  a  C++  version  of  ACE  based  on  a 
commercially  available  object-oriented  database  (McGraw,  J\me  1996). 

Agents  are  expert  systems  that  are  tightly  integrated  with  each  other  using 
libraries  of  objects  such  as  wsdls,  fans,  or  pumps.  Agent-based  systems  are  well 
suited  for  use  as  integration  platforms.  Complex  systems  can  be  gradually 
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implemented  using  many  small  agents,  making  the  system  easy  to  maintain 
since  agents  may  be  changed  internally  or  replaced  without  affecting  the 
remaining  agents.  Although  most  agents  act  under  the  user's  direction,  they  can 
also  run  in  the  background  and  act  in  an  advisory  capacity. 

The  primary  role  of  an  agent  in  ACE  is  as  an  assistant  that  uses  heuristic  rules 
and  a  powerful  checklist  facility  to  automate  routine  tasks,  thus  enhancing 
productivity  and  ensuring  repeatable  work  process  quality.  Experienced  users 
can  store  their  knowledge  in  agents  for  use  by  others.  The  true  strength  of  ACE, 
however,  is  tool  integration.  ACE  offers  the  possibility  of  blurring  the  distinction 
between  data  in  CAD  drawings,  analysis  programs,  and  contract  specifications. 
It  makes  this  integration  possible  by  providing  a  central  database  that  reduces 
redundant  data  input  and  the  associated  risk  of  human  error,  thus  improving 
document  consistency.  ACE  supports  the  Discourse  Model  of  collaboration  (Case 
1996).  Artifacts  in  ACE  take  the  form  of  frames,  generahzed  semantic  Hnks,  and 
constraints,  described  below. 

Frames 

Frames  describe  the  data  structmres  and  behavior  of  system  components  being 
designed,  whether  physical  or  abstract.  In  the  architectmal  domain,  examples 
include  walls,  windows,  and  ductwork.  When  a  frame  is  instantiated,  it  is  often 
referred  to  as  an  instance.  Definitions  of  frames  are  obtained  from  a  frame 
library  that  may  be  shared  by  a  group. 

Semantic  Links 

Semantic  links  represent  relationships  between  frame  instances.  For  example,  a 
wall  that  includes  a  door  would  represent  that  relationship  by  a  has-part 
semantic  link  between  the  wall  instance  and  the  door  instance. 

Constraints 

A  constraint  is  used  to  build  and  enforce  mathematical  and  symbolic  relation¬ 
ships  between  slots  of  instances,  based  on  a  model  used  by  Steele  (1980).  For 
example,  a  constraint  can  be  used  to  require  that  a  wall  outlet  be  located  0.5  m 
from  a  door.  They  are  also  used  to  detect  conflicts  between  users.  For  example, 
if  a  user  has  an  opinion  that  a  window  should  use  glass  with  low  emissivity,  that 
opinion  would  be  represented  by  attaching  a  constraint  to  the  type  slot  of  that 
window,  annotated  with  information  about  the  user  and  agent  that  hold  that 
opinion.  When  several  slots  are  connected  in  series  by  constraints,  values  will 
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spread  through  a  network.  This  capabihty  makes  ACE  well  suited  for  para¬ 
metric  design. 

The  Discourse  Model  supported  by  ACE  uses  knowledge-level  agents 
(Genesereth  1988)  that  manipulate  artifacts  in  a  workspace.  An  agent  repre¬ 
sents  the  user  during  the  design  process  by  manipulating  or  reacting  to  artifacts 
present  in  the  design  context.  In  fact,  human  users  are  not  allowed  to  directly 
manipulate  the  workspace.  Instead,  a  special  user  agent  must  be  provided  by 
the  workspace  to  act  for  the  human  user. 


Library  Representation 

A  common  library  for  the  electronic  modeling  of  product  and  process  information 
has  been  developed  to  provide  a  shared  ontology  with  which  all  participants  can 
create  objects  and  communicate  information. 

The  common  library  representation  is  the  most  critical  component  of  the  colla¬ 
boration  scenario,  which  was  defined  as  a  heterogeneous,  closely  coupled 
(participants  working  closely  together)  environment.  Therefore,  the  ontology 
about  which  cororntmication  is  centered  must  have  fixed  communal  definitions. 
As  part  of  the  demonstration  exercise,  a  vocabrdary  was  developed  that  was 
sufficient  to  conmnmicate  the  contents  of  preliminary  design.  This  vocabulary 
contained  objects,  slots,  facets,  values,  type,  emd  object  inheritance.  Semantic 
relationships  defined  in  the  library  consisted  of  only  “part-of”  and  “is-a” 
relationships.  It  was  the  developers’  intent  to  have  a  minimum  set  of  definitions 
within  the  library  representation. 

By  using  the  common  library  representation,  heterogeneous  agents  communi¬ 
cated  about  objects  on  a  one-to-one  relationship.  No  translation  was  required 
during  communication.  For  example,  when  the  architectural  agent  talks  about 
doors,  the  O&M  agent  understands  exactly  the  same  meaning  for  doors.  By 
working  from  a  common  hbrary  representation,  a  major  hurdle  in  communica¬ 
tion  was  overcome  by  removing  ambiguity  in  the  meaning  of  concepts. 

The  ontology  provided  by  the  representation  included  concepts  from  each  of  the 
disciplines  in  the  demonstration.  Therefore,  the  representation  included  descrip¬ 
tions  of  architectural  zones,  building  components,  construction  time  and  cost 
components,  and  functional  requirements.  Libraries  of  frames  mimicking  the 
common  hbrary  representation  were  created  in  the  ACE  environment.  Using 
these  libraries,  participants  in  the  demonstration  could  create  instances  of  the 
firames  and  could  share  this  information  with  other  users.  Other  participants 
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receiving  this  data  could  understand  the  content  of  the  information  because  their 
libraries  would  be  identical  to  the  one  in  which  the  object  was  originally  created. 


ACE  Interface  to  Computer  Aided  Drafting  Tools 

When  large  amounts  of  data  exist  (which  is  usually  the  case  in  the  facility 
delivery  process),  it  is  essential  that  this  information  be  displayed  in  a  graphical 
manner  (Sriram  1992).  Therefore,  an  important  element  of  the  ACE  system  is 
its  ability  to  graphically  represent  objects  that  are  defined  in  a  shared  library  of 
fi“ames.  CAD  tools  can  he  used  to  display  the  objects.  The  ability  to  communicate 
with  CAD  systems  is  referred  to  as  a  “CAD  interface.”  ACE  presently  has  CAD 
interfaces  using  AutoCAD  Release  12  for  Microsoft  Windows  and  Microstation 
5.0  for  the  Microsoft  NT  environment.  The  CAD  interface  provides  a  two-way 
link  from  the  product  model  representation  in  ACE  to  a  graphiced  representation 
in  CAD.  Groups  of  lines  and  arcs  can  be  displayed  in  a  CAD  drawing  to 
represent  individual  instances  of  data  in  ACE.  The  CAD  interface  has  a  mecha¬ 
nism  for  changes  made  in  the  CAD  drawing  to  be  automatically  reflected  in  the 
associated  ACE  objects.  Likewise,  if  a  user  edits  an  ACE  object  directly,  the 
rendering  can  be  redrawn  to  reflect  these  changes. 

The  CAD  interface  is  implemented  at  the  base  level  using  Microsoft's  D5mamic- 
Data  Exchange  (DDE)  technology,  which  allows  communication  links  to  be 
established  between  separate  applications  running  in  Microsoft  Windows  or  NT. 
Once  a  link  is  established,  messages  containing  strings  of  information  can  be 
exchanged.  With  the  CAD  interface,  messages  are  passed  through  a  link  created 
between  ACE  and  the  CAD  system.  A  message  consists  of  a  “packet”  of  informa¬ 
tion  and  contains  an  operator,  sequence  number,  and  data  element.  A  message 
packet  is  sent  to  CAD  from  ACE,  is  then  decoded  and  evaluated  in  the  CAD 
system,  and  the  result  is  returned  to  ACE  in  an  encoded  message  packet. 

With  the  base  message-passing  link  in  place,  the  system  must  now  allow  the 
user  to  specify  how  instances  of  frames  in  the  shared  fi'ame  libraries  should  be 
drawn  in  CAD.  To  accomplish  this,  drawing  routines  are  written  and  stored  with 
the  ACE  frames.  These  routines  call  CAD  drawing  functions  in  order  to  cause  a 
shape  to  be  drawn  in  a  rendering.  When  such  a  routine  is  called,  the  CAD 
system  returns  a  unique  identifier  for  the  drawn  shape.  This  identifier  is  stored 
with  the  associated  instance  in  ACE.  In  a  similar  manner,  the  ACE  object  sends 
a  unique  identifier  (e.g.,  its  instance  name)  that  is  stored  with  the  associated 
CAD  object.  The  completion  of  these  two  steps  creates  a  two-way  link  between 
both  objects.  Much  of  the  coding  required  to  make  “CAD-aware”  objects  has  been 


42 


USACERL  TR  98/32 


implemented  into  standard  CAD  shape  object  definitions.  A  user  can  create  new 
frames  that  inherit  fi:om  existing  frames  and  have  all  the  code  necessary  for 
graphical  representation. 

With  the  two-way  link  established,  a  menu-  or  icon-driven  user  interface  has 
been  created  to  be  used  in  the  CAD  system.  This  user  interface  can  be  used  to 
create  or  modify  CAD-aware  objects  fi'om  within  CAD.  It  is  then  possible  to  use 
native  CAD  commands,  such  as  the  “move”  command,  to  manipulate  CAD-aware 
objects  and  still  maintain  consistency  in  the  two  representations. 


Virtual  Workspace  Language 

The  information  exchange  between  applications  in  the  two  previously  described 
systems  is  accomplished  using  the  VWL  protocol,  which  is  used  for  communica¬ 
tion  between  programs  having  disparate  representations.  The  VWL  protocol 
incorporates  KIF  and  KQML.  KQML  performatives  describe  messages 
concerning  information  or  knowledge  being  communicated  from  one  program  to 
another. 

Using  the  Discourse  Model,  the  individual  workspaces  used  by  each  human  user 
of  ACE  are  joined  into  VWS,  which  supports  asynchronous  and  distributed 
collaboration.  Although  users  are  working  in  ACE  on  their  own  computers,  in 
effect  there  appears  to  be  one  large  workspace.  A  set  of  workspaces  joined  in  a 
VWS  is  called  a  group.  Each  workspace  in  the  group  is  uniquely  identified  by  a 
userid  code,  which  is  associated  with  the  human  user  of  the  workspace. 

Workspaces  communicate  using  an  electronic  mail  system  called  VWS-Mail.  The 
rationale  for  using  a  mail  system  Einalogy  is  to  provide  message-store  capabilities 
so  that  a  workspace  can  send  a  message  to  another  workspace  with  the 
assurance  that  if  the  other  is  not  on-line,  the  message  will  be  stored  tmtil 
accessed.  Message-store  permits  a  group  member  to  isolate  a  computer  from  the 
network  for  a  period  of  time,  work  on  the  design  (or  perhaps  travel),  and  then 
reconnect  the  computer  to  the  group  and  receive  updated  information. 

Workspaces  coromunicate  with  each  other  by  formulating  and  sending  messages 
in  VWL,  which  is  intended  to  be  used  by  programs  conforming  to  the  Discourse 
Model.  VWL  uses  KQML  performatives  to  send  messages  (Finin  1994).  Its 
principal  verbs  are:  interest,  shadow,  link,  constrain,  conflict,  and  rationale.  For 
more  information  about  VWL,  see  Case  (1994). 
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Integration  With  Commercial/Legacy  Software  Tools 

Architects,  engineers,  and  others  who  are  involved  in  the  facility  delivery  process 
use  commercial  and  legacy  (corporate  information  management  systems)  soft¬ 
ware  tools  to  help  them  accomplish  their  design  and  analysis  tasks.  USACERL 
used  ACE  to  integrate  the  following  software  tools  within  the  agents,  which  were 
developed  to  support  design  and  analysis  tasks: 

•  Microsoft®  Project  for  Windows® 

•  Microsoft®  Excel  for  Windows® 

•  BLAST  (BLAST  Support  Office,  1994) 

•  MCACES®  (MCA  Cost  Estimating  System)  (Building  Systems  Design,  Inc. 
1992). 

Software  Agent  Defined 

Software  agents  are  expert  systems  that  are  tightly  integrated  with  an  object- 
oriented  database,  traditional  CAD,  and  other  engineering  tools.  In  conjunction 
with  the  database,  agents  are  the  glue  that  integrates  various  applications  in  a 
coordinated  design  environment,  and  they  provide  a  repository  for  consistent 
facihty  modeling.  These  systems  have  several  unique  features,  including:  rules 
that  capture  design  knowledge,  constraints  that  allow  logical  connections 
between  related  design  objects,  and  design  rationale  for  decisions  made  by  either 
the  designer  or  agent.  They  are  also  opportunistic — if  any  information  is 
changed,  added,  or  deleted,  they  determine  how  the  agent's  “viewpoint”  is 
impacted  and  respond  appropriately.  Agents  can  automatically  generate  many 
types  of  construction  documents  with  consistency  and  without  the  common 
errors  foimd  using  existing  CAD  systems. 

The  term  “agent”  used  loosely  can  mean  any  piece  of  software  (software  agents) 
or  person  (user  agents)  that  can  possibly  affect  change  to  electronic  data  and/or 
interact  with  other  agents  (Elautz  et  al.  1994).  Software  agents  are  software 
systems  that  operate  within  an  electronic  environment,  which  can  sense  the 
state  of  and  affect  changes  to  this  environment.  For  the  sake  of  brevity,  only  the 
software  agents  used  in  the  testbed  demonstration  will  be  discussed  in  the 
following  chapters.  A  software  agent  usually  consists  of  a  set  of  rules  that  are 
used  to  diagnose  a  problem,  check  for  errors,  or  otherwise  automate  a  task.  In 
ACE,  software  agents  are  miniature  expert  systems  that  can  aide  a  user  in 
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performing  his  or  her  normal  duties.  These  ACE  agents  consist  of  rule-bases 
and/or  checklists  that  step  users  through  plans  to  be  executed,  thereby  allowing 
the  user  to  control  the  manner  in  which  the  agent  performs  work. 
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4  Testbed  Scenario 

Approach 

CE  Testbed  Scenario 

Figure  6  shows  the  key  collaborative  engineering  principles  that  the  testbed 
demonstrates:  intelligent  agents,  information  sharing,  and  conflict  management. 
The  figure  shows  the  participating  agents  involved  in  the  schematic  design 
phase,  software  tools  used,  design  interests,  conflicting  interdisciplinary  view¬ 
points,  and  the  impact  these  could  have  on  the  design  process. 


Current  Participants  and  Software  Agents 
Project  Manager 

The  project  manager  agent  has  two  major  responsibilities:  providing  site 
information  to  all  pertinent  project  members  and  managing  project  coordination, 
project  scheduling,  and  resoiirce  allocation.  Some  of  the  information  created  by 
the  project  manager  includes  project  team  members,  project  milestone  informa¬ 
tion,  site  benchmarks,  site  contour  information,  project  budget  and  duration,  and 
soils  information. 

Architectural  Layout 

The  architectural  agent  enables  the  architect  to  input  a  functional  hierarchy  of 
the  building  program  into  ACE.  Starting  with  a  building  object,  semantic  links 
can  be  developed  between  building  components.  These  building  components  are 
then  placed  in  a  CAD  system  using  the  CAD  Linkage.  For  example,  walls  are 
automatically  generated  from  room  coordinates. 
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Figure  6.  Collaborative  Engineering  testbed  scenario. 
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Early  Cost  Estimating 

Develop  cost  estimates  at  the  programming  stage  of  design  when  the  building  is 
completely  programmed.  The  purpose  of  developing  an  estimate  is  to  confirm 
any  previously  established  tentative  budget.  Assumptions  are  made  about  the 
size  and  form  of  the  building  and  the  building  systems  to  be  used.  Also,  provide 
a  capability  to  compare  costs  of  alternative  building  systems  in  the  conceptual 
design  stage. 

Code  Checking 

Carnegie  Mellon  University  has  developed  a  Building  Standards  Processor  to 
support  the  processing  of  formally  represented  bmlding  codes  and  standards 
during  the  preliminary  design  of  buildings.  A  module  was  developed  to  facilitate 
communication  between  CMU’s  Standards  Processor  and  the  testbed 
demonstration  project  (Hakim  1993). 

Mechanical/Energy 

The  mechanical/energy  agent  is  concerned  with  the  energy  performance  of  the 
facility.  At  the  earliest  possible  stage,  an  agent  conducts  an  analysis  of  the 
thermal  behavior  of  the  facility  eind  recommends  changes  to  improve  the  thermal 
performance.  A  thermal  simulation  using  BLAST  is  performed  so  that  proper 
equipment  type,  size,  and  control  can  be  determined.  The  simulation  results 
provide  information  for  life-cycle  costing,  and  selection  of  fan  system,  coils,  and 
plant  equipment  (Pedersen  1995). 

Construction  Planning 

The  construction  representative  is  concerned  with  the  facility’s  constructibility. 
At  the  earliest  possible  stage,  the  agent  generates  a  preliminary  cost  and 
schedide  for  facility  designs  to  compare  alternative  designs  from  a  construction 
time  and  cost  perspective.  Before  actual  construction  begins,  the  agent  can 
animate  the  schedule  to  verify  it  and  to  identify  constructibility  problems  and 
correct  them.  The  agent  can  provide  a  good  baseline  schedide  and  cost  estimate 
for  evaluation  of  contractor  bids,  and  also  determine  the  impact  on  schedule  and 
costs  due  to  change  orders  and  modifications  during  the  construction  manage¬ 
ment  phase  (Ganeshan  1995). 
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Roof  Design 

The  Support  Environment  for  Design  and  Review  (SEDAR)  for  flat  and  low-slope 
roofs  helps  prevent  errors  dirring  roof  design  by  graphically  marking  areas  on 
the  design  off-limits  for  a  selected  design  object.  SEDAR  also  notifies  the 
designer  as  soon  as  an  error  is  detected,  with  the  intent  of  reducing  the  possi¬ 
bility  of  extensive  redesign.  Finally,  SEDAR  allows  designers  to  seamlessly 
integrate  reviews  based  on  building  subsystems  with  the  design  process.  A 
hierarchically-decomposed,  task-based  model  of  an  experienced  designer,  the 
Designer’s  Task  Model  (DTM)  was  developed  for  flexible  control  of  the  operation 
of  an  expert  critiquing  system  (Fu  1996). 
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5  Testbed  Demonstration 


Once  the  PM  has  performed  his/her  responsibilities,  the  AE  begins  by  placing 
rooms  creating  a  space  layout  plan.  At  this  point  the  design  is  still  a  two 
dimensional  drawing.  From  here,  the  AR  uses  the  expand  room  command  to 
create  the  three-dimensional  object  drawing  (Figure  7). 

This  command  automatically  places  wall,  floor,  and  ceiling  objects  that  are 
semantically  linked  to  the  original  space.  Once  the  rooms  have  been  converted 
to  three-dimensional  spaces,  the  architect  begins  further  development  of  the  plan 
by  the  addition  of  doors,  windows,  roofs,  and  foimdations.  These  items  are 
essential  to  the  collaboration  between  the  AR  and  the  ME. 
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Figure  7.  Inserting  rooms  and  expanding  walls. 
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During  this  development,  it  is  essential  to  gain  crucial  design  information  from 
all  parties  involved.  For  example,  an  ME  wiU  show  his  interest  set  by  sending  a 
message  to  the  AR  through  the  VWS  protocol.  Once  the  AR  has  received  this 
information,  he/she  broadcasts  the  object  model  based  on  the  information  sent 
from  the  ME. 

Once  the  ME  has  received  the  interests  from  the  AR,  he/she  can  proceed  with 
creating  thermal  zones  (Figure  8)  and  running  a  BLAST  simulation.  After  the 
program  has  been  run,  the  ME  can  view  the  results  in  VB  graphics  to  determine 
where  problems  may  arise  in  terms  of  too  much  air  infiltration  or  other  items 
which  may  cause  the  building  to  become  energy  inefficient  (Figure  9). 
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Figure  8.  Creating  a  thermal  zone. 
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Figure  9.  Review  BLAST  simulation  results. 


At  this  point,  the  ME  notices  that,  if  a  certain  window’s  properties  are  changed, 
then  the  residts  of  the  program  would  be  much  different.  To  try  to  help  alleviate 
the  problem,  the  ME  alters  the  size  of  a  window,  which  causes  a  constraint 
violation  to  arise  between  the  ME  and  the  All  (Figure  10). 
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Figure  10.  Constraint  vioiation. 


Through  VWS,  the  AR  notices  the  conflict  and  proceeds  to  negotiate  with  the  ME 
by  choosing  which  conflict  to  negotiate  (if  more  than  one  exists). 

Once  the  conflict  to  resolve  is  chosen  (Figure  11),  the  AR  begins  to  resolve  the 
conflict  with  the  ME  through  videoconference,  telephone,  or  e-mail  (Figure  12). 
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Figure  11.  Choosing  a  conflict  to  negotiate. 
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Figure  12.  Resolving  the  conflict. 


Once  the  conflict  has  been  resolved,  both  parties  can  view  the  results  on  their 
computers  (Figure  13)  and  continue  with  resolving  more  conflicts  or  continue 
with  the  design  process. 
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Figure  13.  Viewing  resolved  conflicts. 


Once  the  mechanical  design  has  been  completed,  the  process  continues  with  the 
roofing  design.  The  designer,  who  is  only  interested  in  the  perimeter  structure, 
will  send  his/her  interest  set  to  the  AR  and  will  broadcast  his/her  object  model  to 
the  roofing  designer.  After  the  perimeter  structure  objects  are  received  by  the 
roof  designer,  he/she  can  proceed  to  design  by  placing  objects  on  the  roof  design 
(Figure  14). 
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Figure  14.  Placing  a  new  object  on  the  roof  design. 


After  the  roofing  design  has  been  completed,  it  is  time  for  the  construction 
planner  to  become  involved  in  the  process.  The  planner  will  similarly  send 
his/her  interest  set  to  the  AR,  who  will  broadcast  the  object  model. 

Once  the  plaimer  has  received  the  interests,  he/she  will  begin  by  developing  the 
building  systems  components  (Figure  15). 
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Figure  15.  Assigning  buiiding  system  aiternatives. 


Once  building  system  development  is  completed,  the  planner  can  continue  the 
process  by  creating  a  preliminary  schedule  for  the  project.  This  schedule  helps 
in  the  initial  design  by  determining  where  delays  will  occtor  and  can  allow  time 
for  the  resolution  of  these  problems  before  they  occur  (Figure  16). 
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Figure  16.  Project  schedule  generation  and  sequencing. 


In  addition  to  showing  the  construction  process  simply  by  timeline,  the  constmc- 
tion  planner  can  demonstrate  the  construction  process  visually  through  com¬ 
puter  animation  (Figure  17). 
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Figure  17.  Construction  animation. 


After  all  parties  have  participated  in  the  preliminary  design,  the  process  starts 
all  over  again.  The  AR  will  take  all  the  information  generated  and  use  this 
information  to  help  better  the  design  and  resolve  problems  to  create  a  more 
efScient  facility. 
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6  Summary 

Lessons  Learned 

Working  on  the  testbed  project  was  a  productive  experiment  in  collaboration. 
Not  only  did  the  researchers  have  to  agree  on  a  vision  of  what  the  testbed  goals 
were,  they  also  had  to  agree  on  how  the  shared  object-oriented  facility  model 
should  be  represented,  and  how  the  software  agents  should  work  together.  It 
was  discovered  that  a  large  facihty  model  was  difficult  to  work  with  within  the 
ACE  environment.  The  testbed  software  did  not  scale  well  for  large  models. 

The  architectural  design  process  using  three-dimensional  (3-D)  objects  is 
different  than  the  traditional  design  process.  The  designer  using  new  design 
tools  is  working  in  3-D  space,  using  3-D  objects,  while  the  designer  using 
traditional  tools  may  still  he  thmking  in  two  dimensions  for  doing  layouts, 
elevations,  and  section  sketches,  then  switching  to  3-D  to  do  renderings.  The 
designer  using  traditional  CADD  tools  or  paper  and  pencil  uses  an  implicit 
representation  of  the  design  artifacts.  For  example,  a  line  may  represent  a  wall 
of  an  undetermined  type.  When  designing  with  object-oriented  tools,  the 
designer  selects  a  wall  object  and  inserts  it  into  an  explicit  representation  of  the 
design  —  a  3-D  model  of  the  facility  being  designed.  Since  a  design  represented 
implicitly  is  subject  to  interpretation,  much  of  the  design  information  is  subject 
to  the  viewer’s  imagination.  Two  people  viewing  the  same  design  may  think  the 
same  line  represents  a  different  item.  A  3-D  model  represented  explicitly  would 
moan  the  same  thing  to  different  viewers,  because  the  designer  has  chosen  and 
inserted  a  specific  object  into  the  model.  Each  viewer  woxild  be  able  to  look  up 
the  object  definition  and,  for  example,  know  which  wall  type  was  used. 

Many  parts  of  the  building  are  not  shown  on  the  drawings  in  either  the  new  or 
traditional  design  process.  Specifications  represent  many  “hidden”  parts  of  the 
building,  while  other  building  parts,  such  as  wiring,  are  shown  schematically. 
Actual  wiring  location  is  typically  decided  by  the  electrician  actually  doing  the 
task. 
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Successful  use  of  new  object-oriented  design  technologies  will  depend  on  several 

factors: 

•  How  does  the  tool  facilitate  architectiural  layout? 

•  Can  the  designer  select  from  a  complete  palette  or  libraiy  of  3-D  objects 
needed  to  represent  walls,  doors,  windows,  building  systems,  etc.? 

•  Can  the  designer  add  xmique  3-D  objects  to  the  library  when  needed? 

•  How  easy  is  it  for  users  to  view  the  design  representation  and  xmderstand 
both  design  intent  and  the  chosen  building  products  and  systems?  This 
information  may  not  be  displayed  as  traditional  drawings  or  specifications, 
but  may  instead  be  represented  in  a  hierarchical  list. 

•  Is  the  designer  able  to  generate  a  complete  set  of  construction  documents? 

•  Are  the  construction  documents  understandable  by  the  owner,  construction 
manager,  and  contractors? 


Current  Trends 

USACERL  is  in  the  process  of  incorporating  lessons  learned  and  functional 
capabilities  developed  during  the  testbed  project  into  the  Modular  Design 
System  (MDS)  (USACE,  January  1997).  Future  versions  of  MDS  will  enable 
designers  not  only  to  design  collaboratively,  but  also  to  identify  and  resolve 
conflicts  from  different  physical  locations. 

USACERL  researchers  also  are  actively  involved  in  the  development  of  Industry 
Foimdation  Classes  (IFC)  as  part  of  the  International  Alliance  for 
Interoperability  (lAI).  Our  experience  in  developing  a  shared  facility  model  for 
the  testbed  helps  us  collaborate  with  others  in  this  international  effort  to  develop 
a  shared  library  of  object  foundations  classes  for  A/E/C  software.  Software  that 
is  IFC  compliant  will  be  able  to  import  and  export  design  files  that  other  IFC- 
compliant  software  generate.  For  example,  an  architect  can  layout  a  building, 
then  share  the  files  with  the  structural,  electrical,  and  mechanical  engineers  who 
design  the  appropriate  building  systems.  A  cost  estimator  with  IFC-compliant 
software  would  be  able  to  generate  a  cost  estimate  using  the  same  design  files, 
without  recreating  information.  Future  versions  of  MDS  will  also  be  IFC 
compliant,  which  will  allow  us  to  gain  access  to  other  IFC  compliant  A/E/C 
software  tools  (httpy/www.interoperability.com). 

Product  manufacturers  have  begun  to  provide  tools  that  enable  designers  to 
insert  brand  name  2-D  eind  3-D  objects  such  as  toilets  and  windows  into  design 
files.  In  the  near  future,  manufacturer-supplied  objects  will  be  available  to 
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designers  via  CD-ROM  or  the  Internet.  Designers  would  be  able  to  select 
“generic”  building  product  objects  for  early  design,  and  possibly  replace  them 
later  with  specific  objects  during  final  design,  or  once  the  contractor  has  selected 
a  particular  product  from  a  manufacturer.  If  these  3-D  facihty  models  are  struc¬ 
tured  properly,  accurate  as-built  information  may  be  collected  and  associated 
with  the  proper  objects.  Then  accurate  as-built  information  would  be  available 
for  facility  managers,  operations  personnel,  owners,  and  others  throughout  the 
life  of  the  facility. 

A/E/C  software  vendors  are  actively  improving  the  capabilities  of  their  com¬ 
mercial  design  tools.  Many  companies  are  participating  in  lAI  and  are  incor¬ 
porating  object-oriented  technologies  into  their  software  packages.  Companies 
are  working  on  development  of  web  servers  for  CADD  drawings,  object  models, 
and  libraries  of  design  objects.  Private  A/E  firms  and  construction  companies 
are  collaborating  together  on  projects  and  using  the  Internet  and  world  wide  web 
to  share  and  distribute  information.  The  Global  Construction  Network  is  a  good 
exeunple  of  partnering  between  private  companies  using  the  Internet  (see 
httpy/www.gcn.net).  Document  management  software  is  improving  enough  to 
allow  companies  to  secxirely  manage  file  access  and  sharing  for  large  design  and 
construction  projects.  Work  flow  management  software  helps  compeinies  route 
documents  through  tlieir  approval  process  electronically.  “Data  warehousing”  is 
developing  to  the  extent  that  organizations  can  securely  store  and  manage  large 
archives  of  electronic  documents.  Together,  these  capabilities  will  enable  the 
A/EJ/C  industry  to  coUaboratively  create  3-D  models  of  facility  designs,  build  the 
facilities,  collect  accurate  as-built  data,  and  share  the  information  throughout 
the  facility’s  life  cycle. 

Future  Research 

The  following  topics  were  found  to  require  additional  research: 

Representation:  Research  is  needed  to  determine  the  best  ways  to  represent 
design  intent,  and  building  products  and  systems  which  3-D  facility  models 
comprise. 

Construction  Document  Generation:  Construction  dociunent  generation  from  3-D 
models  wiQ  require  a  significant  research  effort.  An  opportimity  exists  to  greatly 
reduce  the  time  required  to  generate  construction  documents  and  improve  their 
accuracy  and  legibility. 
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Conflict:  The  testbed  project  verified  that  conflict  identification,  negotiation,  and 
resolution  can  be  accomplished  during  collaborative  design  with  a  shared  facility 
model  in  a  tightly  coupled  environment.  Future  work  should  include  an  in-depth 
examination  of  how  conflicts  can  be  resolved  among  agents  and  users.  Conflict 
identification  and  resolution  is  not  yet  a  capability  available  in  commercial 
A/E/C  software,  and  many  research  issues  remain. 

Loosely  Coupled  Collaboration:  Not  shown  in  this  demonstration  is  how  agents 
and  systems  that  are  loosely  coupled  to  each  other  can  interact.  The  Agent 
Collaboration  Language  (ACL)  project  managed  by  USACERL  involving 
Stanford  University,  CMU,  MIT,  and  UIUC  explored  how  to  design  a  building  on 
the  information  super-highway.  Project  participants  are  dispersed  throughout 
the  United  States  and  use  a  wide  variety  of  representations. 

Object  Server:  The  shared  library  representation  used  in  the  test  bed  demon¬ 
stration  proved  to  be  inefficient,  in  that  libraries  of  frames  mimicking  this  repre¬ 
sentation  had  to  be  created  for  each  software  environment.  This  practice  was 
prone  to  inconsistencies.  Future  research  will  test  the  feasibility  of  an  “object 
server.”  The  object  server  will  be  responsible  for  providing  frame  descriptions  of 
imknown  objects  that  a  participant  receives  via  VWS,  thereby  extending  the 
capabilities  of  a  user’s  workspace.  Quite  possibly  these  representation  schemes 
•will  become  standard  within  a  discipline  and/or  domain,  and  an  object-server 
method  of  sharing  representations  ■will  effectively  facilitate  the  sharing  of 
objects.  Research  on  how  to  manage  shared-object  repositories  and  model 
servers  to  make  them  available  to  distributed  design  teams  over  the  Internet  has 
begim,  but  more  research  is  needed  to  assure  commercial  ■viability  for  large  scale 
projects. 

Assemblies:  It  is  often  desirable  to  copy  portions  of  an  existing  design  into  new 
work  to  reduce  duplication  of  effort.  Future  research  will  investigate  how  to 
facilitate  the  storing  and  sharing  of  groups  of  objects  or  “assemblies.” 

Conclusion 

A  fully  implemented  collaborative  en^vironment  will  significantly  improve  the 
quality  of  decision  making,  contract  documentation  and  related  design  processes. 
Through  agent-assisted  collaboration,  the  extended  design  group  (including 
O&M  and  other  installation  personnel)  works  as  a  coordinated  team.  Software 
agents  will  assist  designers  in  making  optimal  decisions  through  improved 
information  dissemination  and  conflict  management.  Designers  will  have  the 
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capability  to  effectively  consider  a  wider  variety  of  design  solutions  and  evaluate 
additional  alternatives  to  improve  the  quality,  health  and  comfort,  energy 
efficiency,  and  life-cycle  cost  effectiveness  of  the  facility.  Makmg  these  types  of 
analyses  easy  to  perform  will  provide  facilities  that  perform  better  functionally 
and  at  reduced  operational  expense. 
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Agent  Collaboration  Language 
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Architectural/Engineering/Construction 
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Architectural/Engineering  Performance  Information  Center 
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Application  Programming  Interface 

BCO 

biddability,  constructibility,  and  operability 
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building  load  and  system  thermodynamics 
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computer-aided  drafting 
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computer-aided  drafting  and  design 
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computer-aided  facility  management  system 

CE 

collaborative  engineering 
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Civil  Engineering  Research  Foundation 
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cost  of  doing  business  process  action  team 
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current  persistent  ACE 
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Cooperative  Research  emd  Development  Agreement 

DDE 

dynamic  data  exchange 

DOD 

Department  of  Defense 

EMS 

Engineering  Management  Systems 

ER 

Engineering  Regulations 
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Military  Construction,  Army 
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military  construction 

operations  and  maintenance 
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object-oriented 
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